Single-quotes should not allow string expansion about sdk HOT 10 CLOSED

This comment was originally written by [email protected]

Sorry, I can't find a way to change type nor priority. I guess owners will have to change them by hand. It is of course not a "defect", but a design consideration that may definitely be voluntary.

from sdk.

This comment was originally written by [email protected]

Removed Type-Defect label.
Added Type-Enhancement, Area-Language, Triaged labels.

from sdk.

This comment was originally written by [email protected]

Python, for example, has the same behavior of allowing either quote.

from sdk.

Current Dart code heavily relies on the fact that single-quoted strings do interpolate:

    new Element.html('<canvas width="${img.width}" height="${img.height}"></canvas>');

I think the current behavior is desirable for building markup which often contains both double quotes and interpolation.

from sdk.

This comment was originally written by [email protected]

I guess HTML construction is a good-enough argument to get rid of the earlier languages conventions :)

from sdk.

Sounds like we've convinced you there is good reason for the currently specified behavior. I'll close the issue then.

Set owner to @gbracha.
Added WontFix label.

from sdk.

This comment was originally written by [email protected]

Sigh, I wish the perl model was more prolific so it wouldn't maintain it's perpetual rep as unreadible (try showing C if-structures to a business major) - as I honestly think it's the only one that got this right. String processing is one of the primary functions of most languages and C derivatives make this the most painful thing you can do.

"fully-interpolable-text"
'non-interpolable except for escape chars'
qq(fully-interpolable-text) // can use () <> {} [], whatever has least escape pain
q(non-interpolable) // same as qq
qw(one two three) // white-space becomes a list instead of a scalar
 <<EOS
Multi-line
string
fully interpolated
EOS

 <<'EOS'
Multi-line
no interpolation
EOS

Where EOS is replaced by something not found in text-body.

The point isn't the particular symantics used, but the fact that no matter what solution a language provides to minimize unexpected escaping and multi-line issues, unless you allow some kind of escape-friendliness your language will suck for templating of any sort. And I've done a LOT of javascript-side templating that is practically torturous; sometimes requiring CDATA blocks (which destroy intelligent editors). The compiler is the perfect place to accept arbitrary text and escape into simple javascript string-concatenation routines.

from sdk.

This comment was originally written by [email protected]

Dart supports all of these but qw, just slightly different syntax.

from sdk.

This comment was originally written by [email protected]

Ok.. I've gone through the antlr. The PDF should provide a reference similar to the following (probably using a table for the string comparison section)

two = 2
// following is pseudo code: exact-ext == dart-expression
123 == "1${two}3"
123 == '1${two}3'
1${two}3 == @­"1${two}3"
1${two}3 == @­'1${two}3'
1'23 == "1'${two}3"
1"23 == '1"${two}3"
ERROR == "1"${two}3"
ERROR == '1'${two}3'
1'23 == '1'${two}3'
1"23 == "1"${two}3"
ERROR == @­'1'${two}3'
ERROR == @­"1"${two}3"
ERROR == @­'1'${two}3'
ERROR == @­"1"${two}3"
1'23 == '''1'${two}3'''
1"23 == """1"${two}3"""
1'23 == '''1'${two}3'''
1"23 == """1"${two}3"""
1'${two}3 == @­'''1'${two}3'''
1"${two}3 == @­"""1"${two}3"""
1'${two}3 == @­'''1'${two}3'''
1"${two}3 == @­"""1"${two}3"""

Such that """ and ''' also support new-lines.

So I agree that qq(xx) is similar to '''xx''' and q(xx) is similar to @­'''xx'''
And you can KIND of get <<EOS variance by alternating ''' v.s. """.

The main thing it's missing is the ability to safely embed dart code inside a dart string (e.g. textual recursion). Again, a foreign concept to the c-world. But with AJAX based web services that can pass code as arguments, this is CRITICAL and a major failing of existing javascript frameworks.. trimpath, again has horrid reliability given HTML and javascript failings. I would STRONGLY recommend supporting here-documents in dart.

Given the operator overloading, I totally understand not leveraging <<EOS syntax. But how about (I appologize for my lack of memory of antler):

STRING : '@'? MULTI_LINE_STRING
    | SINGLE_LINE_STRING
    | CDATA_BLOCK
    | @­CDATA_BLOCK
;

fragment CDATA_BLOCK: "CDATA" '<' identifier '>' (options{greedy=false): .* ) NEWLINE '<' $3 '>' NEWLINE
;

from sdk.

This comment was originally written by [email protected]

oops, means

STRING : '@'? MULTI_LINE_STRING
    | SINGLE_LINE_STRING
    | '@'? CDATA_BLOCK
;
token {
  CDATA : "CDATA"
}
fragment CDATA_BLOCK: CDATA '<' identifier '>' NEWLINE (options{greedy=false): .* ) NEWLINE '<' $3 '>' NEWLINE
;

Also should include the following examples:
1"${two}3 == @­'1"${two}3'
1"""23 == """1"""${two}3""";
1"""${two}3 == @­"""1"""${two}3""";
ERROR == """1"""${two}3""";

from sdk.