Jochen, 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 <blackd...@gmx.org> 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 >
