groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <blackd...@gmx.org>
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 <paulk@asert.com.au>
> Datum: 11.09.18 16:05 (GMT+01:00)
> An: dev@groovy.apache.org
> 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 <blackdrag@gmx.org 
> <mailto:blackdrag@gmx.org>> 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
> 

Mime
View raw message