One can argue that this should be a static warning rather than a compilation error. And one can argue the other way too. The question is whether treating it as an error is more useful to users. I think this case is, so I'm inclined to leave things as they are, but could be convinced otherwise. I'm also not sure what the implications are for the VM.

Set owner to @gbracha.
Added Accepted label.

Just to clarify: I still want to have a check that it is in the unicode-range 0-0x10FFFF, but I would remove the checks for invalid ranges.
For example: "\u{DC80}".

I think that "\u" (and as consequence "\x") is either used as a means to express a specific rune (for example the G-clef, \u{1D11E}), or, more frequently, to encode an existing string. In that case, the developer could want to encode invalid sequences, and I think we should allow it.

Making it a static warning is ok for me.

I agree that we should allow surrogate values as \u-escapes.

It made sense to not allow them back when Dart strings were UTF-32 encoded, but now that we are using JavaScript strings, which are just sequences of UTF-16 code units, there is on need for the restriction, and it's more of an obstruction than a help.

It is quite possible to have strings containing unpaired surrogates, you just have to create them in a round-about way.

 var string = "ab\uDC12ef"; // fails to compile
 var string2 = new String.fromCharCodes([0x61, 0x62, 0xdc12, 0x65, 0x66]); // works
 var string3 = "ab${new String.fromCharCode(0xdc12)}ef"; // works
 var string4 = "ab" + "\u{10012}"[1] + "ef"; // works

These workarounds have one thing in common: the strings are not compile time constants.

Some users want to store bit patterns as strings (it's the most efficient representation we have for compile-time constant blobs), and it's frustrating when some bit patterns are disallowed by the syntax, even if they are fine as values.

(A better alternative for that problem would be typed-data literals, e.g. [1,2,3]u16 as a Uint16List literal, but we don't have that.)

Thanks for the clarifications. That makes a lo more sense. I'll check with the VM team and TC52.

This comment was originally written by las...@gmail.com

In this case, the change would just be changing "Unicode scalar value" to "code point".

http://www.unicode.org/glossary/#unicode_scalar_value

In Dart terms we use the term "Rune" for code points.
If possible I would mention both,, but if you only want to use one term, "Unicode code point" is what should be in the spec.

Dupe of #26620.