It's worth noting that IntelliJ highlights the unicode escape a
different color within the string literal. The difference is even more
dangerous if you're trying to access some file: """C:\u1234""", that
doesn't trigger a compiler error.
-jason
On 16/06/11 03:59, Jon Clark wrote:
> Scala has historically abandoned Java traditions and even it's own
previous
> design decisions
er?
- --
Tony Morris
http://tmorris.net/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk35IzYACgkQmnpgrYe6r60UrgCgj8ChLGez4vungm5gINklynvq
6E4AoL1nigupUHlByaqrFOVvrxoDs9OX
=55wX
-----END PGP SIGNATURE-----
A good explanation--but that doesn't mean that triple-quoting, which doesn't happen in Java, should behave the same way. The lexer has to understand triple-quotes, so it could also understand to leave \uxxxx alone just like it leaves \n and so on alone.
val x = 1 // the use of \u000a inside a comment causes problems
As other said, but one may be excused to realize to which extent,
unicode expansion is done before anything else. Any place where \uXXXX
appears, that is replaced by the equivalent unicode character.
For example, the following is valid:
val x: String = \u0022A string.\u0022
Personally, I *hate* this. I admit it might have some obscure use,
like C trigraphs, but it is just not worth the trouble, IMHO.
Now, you can forgo unicode escape *completely*, with -Xno-uescape.
Unfortunately, it stops working even inside strings:
scala> val x = "\u000a"
<console>:1: error: invalid escape character
val x = "\u000a"
^
I wish one could go halfway: disable it everywhere *except* inside
single-double quote strings and characters.
--
Daniel C. Sobral
I travel to the future all the time.
val x = 1 // a comment with a \n embedded in it
val y = 2 // a comment with a \u000a embedded in it
It is not that \u is expanded inside strings: it is expanded inside source code.
--
Valid Scala:
https://gist.github.com/1028966
Now we just need a program which generates ASCII-art which is at the
same time valid Scala code.
--
Johannes
-----------------------------------------------
Johannes Rudolph
http://virtual-void.net
Interesting use cases. This is perverse as one can copy/paste these strings without
noticing the \ u sequence... Decomposition is a valid workaround, but again, you must have
spotted the issue beforehand... OK if the compiler complains against a malformed Unicode
literal, bad if you have the bad luck of having a valid one, like:
val f = """C:\test\uuuFeedUs""" // Not what you think if you are not aware of the issue...
BTW, I still haven't understood why multiple u's are accepted... (from Java tradition).
As said, the problem relies probably because an early phase of the parser just blindly try
and convert all escapes it sees in the source code, without caring about context. Fast,
but troublesome...
I never have been fan of these triple quotes anyway (also seen in Python, no?), somehow I
prefer heredoc syntax, with arbitrary end-of-string tag (seen in Perl, PHP...). They
probably come with their own set of issues, but at least they are more flexible.
Hey, at least it is better than Java's rigid syntax... :-)
--
Philippe Lhoste
-- (near) Paris -- France
-- http://Phi.Lho.free.fr
-- -- -- -- -- -- -- -- -- -- -- -- -- --
Yes, actually I do that in most of my programs, as double backslashes look terrible in
Java strings. But the triple quote has the advantage of taking a native Windows string (as
copy/pasted from the address bar, for example) and it is sad we hit such limitations.
And Windows paths aren't the only issue, as the OP rightfully shown in his initial
message... Beside LaTeX, we might need to manipulate registry paths (eg. to generate a
.ref file, for installation or other):
"""[HKEY_CLASSES_ROOT\Directory\shell\unlimitedApp]"""
or RTF:
"""Font styles: \b bold\b0 , \i italic\i0 , \ul underlined\ulnone ."""
and so on.