I checked a couple quick examples and the AST represents these as CastExpressions, not ConstructorCallExpressions. That may help shed some light on the case for @Newify which inserts actual CCEs into the AST.
date = Date[year: 1990] // cast date = (Date) [year: 1990] // cast date = [year: 1990] as Date // cast/coerce date = new Date(year: 1990) // constructor call With that in mind, I think that "Date[:]" should work exactly the same as "(Date) [:]" and "[:] as Date" work. ________________________________ From: mg <mg...@arscreat.com> Sent: Wednesday, September 5, 2018 9:21 AM To: dev@groovy.apache.org Subject: Re: Constructor call short-hand syntax PS: I would love to get rid of @Newify and have Groovy simply support class instance creation with and without new keyword (maybe only for classes whose name starts with an uppercase letter, for performance reasons), same as eg Python or Jetbrain's Kotlin does. @Newify is a compromise, and I am happy that we do now have the pattern parameter. Btw, do we have an eta for IntelliJ @Newify(pattern=...) support ?-) -------- Ursprüngliche Nachricht -------- Von: Daniil Ovchinnikov <daniil.ovchinni...@jetbrains.com> Datum: 05.09.18 14:54 (GMT+01:00) An: dev@groovy.apache.org Betreff: Re: Constructor call short-hand syntax I didn’t know that it’s a shorthand constructor syntax when I’ve created a ticket. I thought it should just work as shorthand for getAt call: a[1, 2] == a.getAt(1, 2) a[x: y] == a.getAt(x: y) a?[1, 2] == a?.getAt(1, 2) // this works already a?[x: y] == a?.getAt(x: y) And now I see it as a perfect Groovy-style replacement for @Newify. Why even @Newify exists if Groovy already had Person[name: “John”, age: 42] syntax? If such syntax exists, why not extend it to be equivalent to Person.class.getAt(name: “John”, age: 42), where getAt on a class instance would instantiate a new object ? The last question implies that getAt would work with any arguments, including named ones. — Daniil Ovchinnikov JetBrains On 5 Sep 2018, at 01:22, Paul King <pa...@asert.com.au<mailto:pa...@asert.com.au>> wrote: On Wed, Sep 5, 2018 at 2:52 AM Jochen Theodorou <blackd...@gmx.org<mailto:blackd...@gmx.org>> wrote: Am 04.09.2018 um 06:49 schrieb Daniel Sun: > Hi Paul, > > Safe index is only for accessing the elements of collections and object > properties, but not for creating instance. The collections and objects may > be null, so we designed the "safe" index. > > To sum up, I vote -1 to support syntax like `Date[time:0]`, the class > instance will not be null. I think you actually miss the point a little. Let me rephrase... should we support somMap?[x:y] for example. I personally think we can take supporting things like x[y:z] and x?[y:z] as future project... if we find a nice use case for this. We certainly could ... but we don't have such a proposal in front of us right now, so it's whether we'd like to cater for the current situation in the meantime with an improved error message. We could remove such an error message at a future point if we have an acceptable proposal. Having said that, it's hard to pick up this error case here without also making the missing : within a ternary error message look more complex. You'd basically need an error message that coped with both cases. Hence my suggestion to close as "Won't fix". (But fix up the empty Map edge case only - without safe decorator). bye Jochen
