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 <pa...@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 <blackd...@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
