Just thought I'd mention list and map constructors [1], with those you can not only leave out the `new` keyword but also leave off the type (at least on the RHS)

Foo foo = ['abc']

[1] http://groovy-lang.org/semantics.html#_list_and_map_constructors

On Tue, Aug 22, 2017 at 4:16 PM, MG <mgbiz@arscreat.com> wrote:
Hi Paul,

On 21.08.2017 04:30, Paul King wrote:
Always allow ctor calls without new keyword:

final foo = Foo("abc") // creates a new Foo instance by calling Foo class ctor with signature
Rationale: new keyword was necessary in C++ to distinguish heap vs stack variable allocation. No such need exists in Groovy, so the keyword just clutters the source code. Naming convention of method names being always lowercase prevents name clashes with methods.

 A partial solution to this is available via @Newify. As far as I know, @Newify hasn't been super popular, so we'd need to think carefully about introducing this.

I am not surprised that the @Newify annotation (http://docs.groovy-lang.org/latest/html/api/groovy/lang/Newify.html) is not popular: When I first read the Groovy documentation (somewhere around 1.8.x) and came across @Newify, I was "Yes - fanta... wait... you have to do what ?". It felt like a feature that was introduced to kill it off immediately...
The Ruby Foo.new(...) syntax falls short for me, since it basically just moves the "new" String around, i.e. it does not make the code much more readable / compact. And for the Foo(...) style, you have to give the classes it shall work for explicitely in the @Newify, which is imho too cumbersome.

If @Newify with Foo(...) ctor calls would work without arguments, one could apply it through a compiler customizer, so can you tell me the rationale for not going down that route (and if the rationale ist still valid in 2017 ;-) ), together with the cryptic "The annotation is intended to be used sparingly" in the @Newify doc ?

For me, getting rid of "new" would be as Groovy as e.g. dropping the semicolon end of line character - which was not necessary since the days of K&R - or being able to give the Closure argument like a block construct :-)

Now crush my hopes with some backward-compatibility-Groovy-insider-error-situations-handler-reason,