effective dart: advice on unnamed vs. constructor tear-off `new` constructors?

[pq]

What information is missing?

With constructor tear-offs, there is a "new" way to define the unnamed constructor for a class.

class A {
  A.new();
}

Do we want to discourage people from using this syntax and prefer the less magic, more familiar (and equivalent):

class A {
  A();
}

?

How would you like us to fix this problem?

It'd be great if there were an effective dart ruling either way.

/cc @munificent @srawlins

[lrhn]

I'm considering writing a FAQ for the constructor tearoffs feature(-set).
My take, so far, on this is:

Q: Should I use .new or not. What does the style guide say?

A: The style guide says nothing yet. The general rule is to not write something which isn't necessary, so don't write new unless you need to. For now, only use it for tear-offs and possibly DartDoc (it will be more Dart-like to write [C.new] than the current DartDoc-only [C.C] to refer to the unnamed constructor). Don't ever write new Foo.new().

[pq]

dart-archive/linter#2919 lands unnecessary_constructor_name. Here are the docs I threw together. Comments and feedback are welcome!

---

unnecessary_constructor_name

PREFER using the default unnamed Constructor over .new.

Given a class C, the named unnamed constructor C.new refers to the same
constructor as the unnamed C. As such it adds nothing but visual noise to
invocations and should be avoided (unless being used to identify a constructor
tear-off).

BAD:

class A {
  A.new(); // LINT
}

var a = A.new(); // LINT

GOOD:

class A {
  A.ok();
}

var a = A();
var aa = A.ok();
var makeA = A.new;

[munificent]

I love the linter rule and I agree with Lasse that the general "If there's two ways to do it, pick the short one" rule applies here and users should not use .new unless they are creating a tear-off.

I don't know if we need a specific "Effective Dart" rule for this. I'm inclined to leave it out and see if users naturally do the right thing. I'm always sensitive to "Effective Dart" being so long that readers get overwhelmed and avoid it entirely, so whenever I can omit a rule, I like to.

[kwalrath]

I agree. Minimalism is good. We can always add this later if it becomes a problem. Shall we close this issue?

[pq]

I'm happy closing it and waiting to see what happens in the wild.

Thanks all for the thoughtful conversation!