Allow passing constructors as functions

[vsmenon]

Support tearing-off and passing constructors similar to current support for functions. Example:

class Text {
  String label;
  Text(this.label);
}

void main() {
  // Tear-off the `Text` constructor and pass it to the `map` function.
  List<Text> l = ['foo', 'bar', 'baz'].map(Text.new).toList();

  // Print all text labels.
  for (var t in l) {
    print(t.label);
  }
}

• Language proposal:
  https://github.com/dart-lang/language/blob/master/accepted/2.15/constructor-tearoffs/feature-specification.md

---

Original issue filed by @rhcarvalho on February 11, 2019 10:59 as dart-lang/sdk#35901

This feature request intends to allow using constructors where functions with the same type/signature are expected.

Example code: https://dartpad.dartlang.org/9745b0f73157959a1c82a66ddf8fdba4

Background

As of Dart 2, Effective Dart suggests not using the new keyword and removing it from existing code.
Doing that makes named constructors and static methods look the same at call sites.

The Language Tour says (emphasis mine):

Constructors
Declare a constructor by creating a function with the same name as its class [...]

Thus suggesting that a constructor is a function. But it turns out it is not really a function, as it cannot be used in all contexts where a function can.

Why it would be useful

Dart built in types, in particular collection types, have several methods that take functions as arguments, for instance .forEach and .map, two concise and expressive ways to perform computations.

In an program I'm working on, I got a bit surprised by not being able to create new instances using Iterable.map + a named constructor. And then I realized that others have arrived at the same conclusion at least 4 years back on StackOverflow, but I could not find a matching issue.

Example Flutter code

What I would like to write:

  return Column(
    // This won't compile:
    children: [
      Heading('Children:),
      ...['Alice', 'Bob', 'Charlie'].map(Text.new),
    ]
  );

What I have to write instead with Dart 2.1.0:

  return Column(
    // Need a dummy wrapper around the constructor:
    children: [
      Heading('Children:),
      ...['Alice', 'Bob', 'Charlie'].map((name) => Text(name)),
    ]
  );

Note that the feature request is not specific to Flutter code, but applies to any Dart code as per the more generic example in https://dartpad.dartlang.org/9745b0f73157959a1c82a66ddf8fdba4.

[rhcarvalho]

@tatumizer thanks for the comment. I see the ambiguity in the unnamed constructor case.
It seems to me that a similar disambiguation happens for example with Callable Classes:

class Greeter {
  final String name;

  Greeter(this.name);

  void call(String who) {
    print('${name} says: Hello ${who}!');
  }
}

void main() {
  var t1 = Greeter('Callable class 1');
  print(t1.runtimeType); // Greeter

  Function t2 = Greeter('Callable class 2');
  print(t2.runtimeType); // (String) => void

  ['Alice', 'Bob'].forEach(t1);
  // Callable class 1 says: Hello Alice!
  // Callable class 1 says: Hello Bob!

  ['John', 'Mary'].forEach(t2);
  // Callable class 2 says: Hello John!
  // Callable class 2 says: Hello Mary!
}

I originally run into this when I wanted to pass in a named constructor to List.map.
What felt surprising to me is that almost everything that is "callable" in Dart can be used as a function, except for constructors.

If the proposal was limited to consider only named constructors, I feel it would create a usability problem, by introducing more exceptional behavior instead of generalizing a concept.

I found now this similar issue (but AFAIU different) dart-lang/sdk#10659, confirming other people have run into this in the past. Apparently using constructors as functions was a thing at some point and then got removed.

Looking forward to hearing more feedback. Thanks!

[lrhn]

There is a precedent in Dart for changing the meaning of expressions based on context type. We do it for double literals, generic function instantiated tear-off and callable objects.

Usually we only change the behavior if the existing behavior is a compile-time error (like assigning a Type to a function type).

The way to tear off the unnamed constructor is the only non-trivial part of constructor tear-offs. Using the context type to enforce the conversion is very similar to how we convert callable objects to functions, as if we are treating Type objects as having a call method.

It won't be done that way, though. We probably have to constrain the tear-off to type literals, so Function f = Object; works, but Function f = (Object); does not, because that's just an arbitrary expression with type Type. We need the static link to the class to know whether there is a constructor to tear off.

[eernstg]

We can make Text work, but the larger amount of mental work that we pile up (for every developer, all the time) because the source code is ambiguous (and you don't know what it means before you have computed a lot of types, maybe in your head), the more we are asking developers to waste their time doing disambiguation.

I think it's very easy to underestimate this kind of work, and it's probably worthwhile to spend some syntax on making the disambiguation explicit. This makes Text.new more attractive than Text + compiler smarts.

Comparing with int-to-double conversion, I think it's fair to say that the difference is smaller with the numbers (there's a big difference between the semantics of getting a type reification and tearing off a constructor, but evaluating 1 to an integer or to a double sort of "means the same thing"), so choosing between a Type and a function object requires a deeper kind of double-thinking. Similarly, comparing with generic function instantiation we also have the same kind of entity (without the conversion f is a generic function, with the conversion it is a non-generic function; but it is, arguably, still "the same function").

[andreashaese]

I'd love this feature! I also agree that Text.new is more obviously a constructor than Text in the described context, especially in concert with named initializers. It's a bit unfortunate that new doesn't have an actual implementation in the type (so you can't search for it by name), but that could be mitigated if IDEs treats new as a symbolic link to the unnamed initializer.

[DanTup]

Text.new seems a slightly weird to me, it looks like a defined member (and what happens if there is one with that name? or if it's a const constructor? :-))

[andreashaese]

It seems impossible to implement a named constructor called new at the moment, so I guess that would not interfere with existing code. Excuse my ignorance, what would change if it was a const constructor?

I'm obviously not working on the Dart compiler, so my ideas are naïve at best. But could Dart not synthesize a new constructor during compilation, that mirrors the accessibility and signature of the provided default constructor and forwards any parameters to the default one? In Swift, when you define a type (Struct) and don't provide an initializer, the compiler does this:

struct Person {
    let name: String
}

let alice = Person(name: "Alice")
let people = ["Alice", "Bob"].map(Person.init)

Notice also how Person(...) and Person.init(...) are similar to Text(...) and Text.new(...).

[natebosch]

Text.new seems a slightly weird to me

My hope is that we'd get used to it quickly and it would stop seeming weird 😄

what happens if there is one with that name?

It isn't allowed. new is a reserved word and so it cannot be the name of a constructor, static, or instance member.

or if it's a const constructor?

Shouldn't be a problem. All const constructors also work as non-const constructors. If you can reasonable tear-off the unnamed constructor, referring to it as ClassName.new shouldn't have any impact other than disambiguation against the Type instance.

[DanTup]

It seems impossible to implement a named constructor called new at the moment

Ah, I hadn't considered that - I guess it's a reserved word. Feels a little less weird now.

Excuse my ignorance, what would change if it was a const constructor?

IIRC, you can normally call a const constructor with either const or new and it'll do different things (eg. if you call using const twice with the same args, you'll get the same instance, but you won't if you call using new). It's not clear which behaviour you'd get here if it was a const constructor and you used Person.new? Maybe it could be handled by supporting Person.const in addition to Person.new. (I'm just thinking out loud, I also don't work on compilers/language design)

[dcov]

What about doing:

data.map(new Text);

It's not the best looking but it gets the point across that it's a constructor and not a function, while also allowing for named constructors:

data.map(new Text.rich);

It also gives a reason to use new 😄

[DanTup]

When you tear off the constructor, it becomes a regular function to which the notion of constness doesn't apply

Oops.. it was late.. for some reason I had something like const ["x", "y", "z"].map(Class.const) in my head, but of course that wouldn't be very constant going through map.

[eernstg]

@andreashaese wrote:

It seems impossible to implement a named constructor called new at the moment

Constructor names are generally of the form C.n or C, where C is the name of the enclosing class, and the latter one is sometimes described as nameless, default, etc. We could allow for new as an alternative syntax:

// Today.
class MyNameIsIrritatinglyLong {
  MyNameIsIrritatinglyLong();
}

// Possible alternative.
class MyNameIsStillIrritatinglyLong {
  new();
}

Of course, it could be helpful to standardize on this such that a search for new will always find the "nameless" constructor, and there could be other arguments that new should not be used any more at all, etc. But it would fit well with the use of terms like Text.new for a tear-off. ;-)

[eernstg]

@vsmenon wrote:

shorthand tear-off within the class will be possible, too (by implication!)

We don't have to allow the bare new for a tear-off inside the class. The fact that it is possible to have a named constructor C.foo and an instance member foo already serves as a hint that we might want to use C.foo rather than foo for constructor tear-offs, also inside C. So we'd just have C.foo and C.new everywhere for tear-offs, which doesn't seem all that inconsistent.

What not to love here? :)

Dunno. ;-)

[andreashaese]

Edit: You beat me to it.

Shorthands of new could be disallowed. In Swift, you're forced to prefix an initializer with its type:

struct Test {
    init() {}
    
    static func staticTest() {
//        let initializer = init // error
        let initializer = self.init
        let instance = initializer()
    }
    
    func memberTest() {
//        let initializer = init // error
        let initializer = type(of: self).init // or Test.init
        let instance = initializer()
    }
}

Another solution could be to standardize default constructors to be named C.new as in

class MyNameIsStillIrritatinglyLong {
  MyNameIsStillIrritatinglyLong.new();
}

but I actually find it appealing that I don't have to type the name of the class in the constructor.

[eernstg]

appealing that I don't have to type the name of the class in the constructor

But then we might want this:

class MyNameIsStillIrritatinglyLong {
  new();
  new.named();
}

It might not work in all details, but the short spec would be "In a constructor declaration signature, the name of the class can be replaced by new".