Please do not understand wrong. I am only saying that this is useless
for Groovy... as was for example generics. That does not mean we will
not support it. And since I do see usage for this in Java an people will
surely start using it, I think we should support it as well.... without
GString interpolation.
Am 11.09.2018 um 17:14 schrieb mg:
I also thought we already agreed on that. I do get where Jochen is
coming from, however not supporting this less mainstream but certainly
useful in certain scenarios Java syntax will imho not help with the
problem that Groovy supports a large number of different (G)String
literals with a non-unified syntax.
-------- Ursprüngliche Nachricht --------
Von: Paul King <[email protected]>
Datum: 11.09.18 16:05 (GMT+01:00)
An: [email protected]
Betreff: Re: [Proposal] GString is implemented eager and treated as
normal String since groovy 3.0.0
IIUC, raw strings don't escape unicode as well as not supporting
interpolation or backslash escaping.
I think we'll inevitably need to look at supporting it.
On Tue, Sep 11, 2018 at 9:16 PM Jochen Theodorou <[email protected]
<mailto:[email protected]>> wrote:
Am 11.09.2018 um 12:16 schrieb Paolo Di Tommaso:
> I mean that Java.next’s syntax for raw strings does not support
variable
> interpolation. My understanding is that groovy won't either.
we have actually 4 multiline string variants, of which 1 is not
supporting variable interpolation
http://groovy-lang.org/syntax.html#_string_summary_table
What the Java version does and we not, is having no interpolation for
escapes. We have the dollar-slashy-string to have a different escape
symbol, but without escapes (raw strings) is nothing we have.
And actually I don't think we need raw string literals in Groovy at
all... but that might be because I do not see good use for them beyond
regular expressions, and for those we have a solution in Groovy already.
bye Jochen
