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 <[email protected]> wrote:
> 
> 
> 
> On Wed, Sep 5, 2018 at 2:52 AM Jochen Theodorou <[email protected] 
> <mailto:[email protected]>> 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

Reply via email to