groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alessio Stalla <>
Subject Re: [Proposal] GString is implemented eager and treated as normal String since groovy 3.0.0
Date Thu, 13 Sep 2018 08:11:00 GMT

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

View raw message