Single-quotes should not allow string expansion

[DartBot]

This issue was originally filed by [email protected]

---

It is a de facto standard, introduced with the shell and taken for granted in other languages that use dollar for expansion (PHP as the main example), that single quotes prevent all expansion.

The example:
  print('fib(20) = ${fib(20)}');
therefore exhibits an unconventional behavior in that it will expand the expression inside dollar-preceeded-brackets.

I would expect Dart to behave more conventionally by requiring double-quotes for inner string expansion, or single-quotes with concatenation.

[DartBot]

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.

[DartBot]

This comment was originally written by [email protected]

---

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

[DartBot]

This comment was originally written by [email protected]

---

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

[munificent]

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.

[DartBot]

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 :)

[gbracha]

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.

[DartBot]

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.

[DartBot]

This comment was originally written by [email protected]

---

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

[DartBot]

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
;

[DartBot]

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""";