That's why I suggested we might consider introducing an annotation (called e.g. @GStringLiteralToString) which allows to switch this behavior, together with an explicit syntax (e.g. S"..." / G"...") for forcing a string literal to give a String/GString.

The S"..." / G"..." syntax could potentially also be used to unify string literal variants and allow to support less often used variants, by adding paramters, e.g.:

def groovySourceLine = S(escape:false,interpolate:true,end:'%&!§')"final x="\n$xVal" // sets x to "\n" (newline) char + xVal.toString()"%&!§


On 13.09.2018 21:05, MG wrote:
Hi Alessio,

nothing wrong with that, same as for the other, more explicit options:

final String x = 'abc'

String s0 = "x=$x"
def s1 = (String) "x=$x"
def s2 = "x=$x" as String
def s3 = "x=$x".toString()

But I believe Jochen is right in saying that people expect

def s4 = "x=$x"

to give a String, which of course it currently does not:

[s0, s1, s2, s3, s4].eachWithIndex { final o, final int i ->
  println "$i) ${o.getClass()}: $o"

0) class java.lang.String: x=abc
1) class java.lang.String: x=abc
2) class java.lang.String: x=abc
3) class java.lang.String: x=abc
4) class org.codehaus.groovy.runtime.GStringImpl: x=abc


On 13.09.2018 10:11, Alessio Stalla wrote:

what's wrong with
String s = "this is a GString literal"
for people who want a String?
If the problem is type inference, then in
def s = "this is a GString literal"
s could be inferred to be a String, while in
GString s = "this is a GString literal"
s would be a GString. Similarly for parameters and return values. If you want a GString or pass a GString to a method, you get a GString, otherwise a String. No need to change the semantics of the GString class itself.

On Thu, Sep 13, 2018, 10:01 Jochen Theodorou <> wrote:

Am 12.09.2018 um 13:59 schrieb mg:
> But do they expect GString to be immutable, or do they expect a GString
> literal to return a String instance (ie for toString() being called
> implicitely on it) ?

they expect it to be a literal to return String. Us being able to assign
a GString to a String does not improve that impression

> I would expect the latter. At least I was not aware that the Groovy
> "GString concept" is actually based on a GString class when I started
> out with Groovy - using def everywhere together with the fact that
> Groovy toString|s GString|s when a String is expected do a great job of
> obfuscating that.

yepp, was actually a goal. GString was supposed to be like a subclass of
String. But I never considered that people may not expect subclasses of

> The question is, where does that lead us... ?

I think we need a way similar to GString literals to construct strings.
Either something new, or change GString to something else

bye Jochen