Make new optional

[Zectbumo]

I see how new makes it familiar to new programmers but the new keyword is really not necessary in the end. Dart has named constructors and static methods and it is up to the library maker to decide which is appropriate to use. Currently named constructors need `new' while static methods do not. My focus here is to relieve the programmer of having to remember what side of the bed the library developer woke up on and remembering do I need the new keyword or not.

Story time:
One day a library developer woke up and said parsing ints from strings is "discovering" the int so therefore it is not a constructor and a static method instead: Integer.parse(); was born. The library user MUST NOT use new to construct this Integer. Then another morning a library developer makes Element.html() and this time he think this is a constructor. The library user MUST use new to create his Element. This requires the library user to stop and think, do I need new or not?, when really in the end the library user just wants an object created; it doesn't matter how it's made.

Before:

var now = new DateTime.now();
var num = Integer.parse('54');
var elm = new Element.html(<u>54&lt;/u&gt;');

After (optional):

var now = DateTime.now();
var num = Integer.parse('54');
var elm = Element.html('<u>54</u>');

A discussion in issue #18241 talks about making const and new together being optional. This issue was created to focus on just making the new keyword optional.

[DartBot]

This comment was originally written by @zoechi

---

What about cases without a named constructor or do you propose to use only named constructors?
var car = Car.new(); // rather ugly in my opinion.

[DartBot]

This comment was originally written by norman...@gmail.com

---

'new' makes it clear that we instantiate new object, not referencing to existing variable.

[Zectbumo]

…do you propose to use only named constructors?
var car = Car.new(); // rather ugly in my opinion.

No. Nameless constructors are fine the way they are.

What about cases without a named constructor…

For consistency sake I would say make new optional there as well.

var buf = new StringBuffer();
or
var buf = StringBuffer();

I think it's pretty clear what is going on here. Even if new is made to be required in the nameless constructor case and optional in the named case then I would understand. I leave it in your hands to make the call.

[DartBot]

This comment was originally written by @Emasoft

---

Please don't. That would make the code much less readable. You would not be able to distinguish methods calls from class instantiations anymore.
Also using static constructors give no advantage at all.
You have to type the same number of characters for:

var car = Car.new();
or
var car = new Car();

It is completely useless, and it would drastically reduce readability of code.

[DartBot]

This comment was originally written by @richardeakin

---

Please don't. That would make the code much less readable. You would not be able to distinguish methods >> calls from class instantiations anymore.

In other languages that don't require the new keyword to make an object, like C++, python, and newer language's like Apple's swift, method calls and class instantiation is completely distinguishable. The reason is simply that the way you write the code makes it clear (method names start with lower case, classes start with upper case). In all practicality, this is all the information you need to determine when a new object is constructed, as 98% (or more) of all code out there follows by this simple style rule.

I'll even go as far as to say that it really doesn't matter anyway, I've never had a problem with 'knowing where something was originally constructed' using the C++ standard library (constructors look_like_this()), methods can always return a newly constructed object and you would not know at the call site. If one is worrying about something like where objects are constructed, there are probably much larger things wrong with the structure of their codebase.

[anders-sandholm]

Added Area-Language, Triaged labels.

[DartBot]

This comment was originally written by nino.porcino...@gmail.com

---

if 'new' is made optional, then also 'const' (from constant constructors) should be optional too. The semantic should be:

var p = Point(); // alias for var p = new Point(); if Point is normal constructor
var p = Point(); // alias for var p = const Point(); if Point is const constructor

[Zectbumo]

if 'new' is made optional, then also 'const'

No, optional const has it's own issues. See issue #18241

[Zectbumo]

If the use of new is important to you then it should be an entry in your style guide to prefer new.

[lrhn]

Since we have factory constructors, there really is no functional distinction between:

class C { factory C.foo() => expr; }

and

class C { static C foo() => expr; }

Constructors are intended to be a recognizable way to get objects of a type. If I want a Foo, I'll look at Foo constructors to see which one I can use.
I could just as well be looking at static functions that return Foo.

The reason factory constructors exists is that if you use a constructor, then the call points use "new", and then you can't replace the constructor with a static function. If there hadn't been a "new" operator, and being a constructor was a property of a method, not of its usage, then there would be no need for factory constructors.

(By extension, a feature that makes sense for factory constructors, like being a delegating factory constructor, could just as well apply to all static methods).

[DartBot]

This comment was originally written by @seaneagan

---

Constructors are intended to be a recognizable way to get objects of a type. If I want a Foo, I'll look at Foo constructors to see which one I can use. I could just as well be looking at static functions that return Foo.

Yep, the api doc tool could even consider those to be "Constructors" and group them for the user. With the current setup if the api user needs to first look through the constructors and static methods to determine all the ways to create an instance, and they need to remember which category each falls into rather than just remembering the name.

The reason factory constructors exists is that if you use a constructor, then the call points use "new", and then you can't replace the constructor with a static function.

But as an api user there's nothing that guarantees me that the api author won't refactor to a static method, if new were optional then api authors can omit it to protect themselves from such a refactoring. And same goes for the reverse refactoring from static method to refactoring, an optional new would protect users from that as well.

If there hadn't been a "new" operator, and being a constructor was a property of a method, not of its usage, then there would be no need for factory constructors.

Of course we would need generic methods (issue #254) for that, which would be great to have anyways. And there would need to be a way to create an unnamed static method, which wouldn't be too difficult to come up with a declaration syntax for.

[DartBot]

This comment was originally written by @Emasoft

---

A programming language must be EXPRESSIVE. Because if it is not, it is not easily readable. And if it is not easily readable it is much more difficult to learn, much more difficult to find errors in the code causing bugs, and much more difficult to integrate the code written by other developers and to understand how it works. Being EXPRESSIVE is now considered a major feature of a language. And:

var car = Car();

is less expressive than:

var car = new Car();

because just reading the former I cannot infer if Car() is a Method or a Class, while if I read the latter I can infer that Car() is a Class at a glance.

This is why using the "new" keyword is so much better than not using it. There are other possible advantages, but this is the main one.

[Zectbumo]

because just reading the former I cannot infer if Car() is a Method or a Class

Incorrect, you can infer Car is a class because the C is capitalized.

[DartBot]

This comment was originally written by @richardeakin

---

because just reading the former I cannot infer if Car() is a Method or a Class

Incorrect, you can infer Car is a class because the C is capitalized.

I agree, and moreover you really don't need to know whether the method is a constructor or a class - you just need to know that it returns a new variable of type Car.

I believe the use of new keyword is more familiar to those who have had the habit engrained into them by working with java, javascript, or c# for a long time. Many others find the following statements much more expressive:

var pt = Point( 2, 3 ) + Point( 4, 5 ) + Point( 6, 7 );

as compared to what is currently required (and appears to only be for stylistic and habitual reasons):

var pt = new Point( 2, 3 ) + new Point( 4, 5 ) + new Point( 6, 7 );

Honestly, when I was reading response #­12, I thought he/she was going to be in favor of making new optional until he/she began writing example code!

About expressiveness, I think it is more than just being readable - it is also about being able to efficiently code your thoughts. I think writing new 3 times in one line hinders this goal, IMO.

[DartBot]

This comment was originally written by @richardeakin

---

Sorry for typos, meant to write:

"...you really don't need to know whether Car() is a method or class constructor..."

Anyway point being, it returns a variable that didn't exist before that line, that is sufficient.