groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paco Zarate <conta...@nazcasistemas.com>
Subject Re: [Proposal] GString is implemented eager and treated as normal String since groovy 3.0.0
Date Tue, 11 Sep 2018 16:05:40 GMT
http://openjdk.java.net/jeps/326 says:

A different delimiter was required to signify different interpretation
behavior. Other languages chose a variety of delimiters:

*Delimiters*

*Language/Tool*

"""..."""

Groovy, Kotlin, Python, Scala, Swift

`...`

Go, JavaScript

@"..."

C#

R"..."

Groovy (old style)

R"xxx(...)xxx"

C/C++

%(...)

Ruby

qq{...}

Perl

[...]

Is the R"..." Groovy old style notation still around?


On Tue, Sep 11, 2018 at 9:14 AM, mg <mgbiz@arscreat.com> wrote:

> 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>
> 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