groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <>
Subject Re: [Proposal] GString is implemented eager and treated as normal String since groovy 3.0.0
Date Tue, 11 Sep 2018 16:32:27 GMT
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 <>
> Datum: 11.09.18 16:05 (GMT+01:00)
> An:
> 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 < 
> <>> wrote:
>     Am 11.09.2018 um 12:16 schrieb Paolo Di Tommaso:
>      > I mean that’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
>     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

View raw message