Why no function overloading?

[Broc Seib]

Dart doesn't permit function overloading. Does anyone know the design decision/tradeoff behind this? Does this just simplify life for dart2js, or is there some other underlying limitation? Or was it just unwanted?

[Greg Lowe]

Function overloading requires static types. Dart at its core is a dynamically typed language.

[Bob Nystrom]

On Tue, Apr 22, 2014 at 2:29 PM, Greg Lowe <greg...@gmail.com> wrote:

Function overloading requires static types.

Only if you statically dispatch the overloads. CLOS has multimethods without a static type to be seen. :)

- bob

[Justin Fagnani]

Right. The more accurate reason is that type annotations are not allowed to affect the behavior of the program. If the overloads were based on the annotations of the function parameters, it would violate that tenet.

--
For other discussions, see https://groups.google.com/a/dartlang.org/
 
For HOWTO questions, visit http://stackoverflow.com/tags/dart
 
To file a bug report or feature request, go to http://www.dartbug.com/new

To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.

[Greg Lowe]

> Or was it just unwanted?

It is also interesting to note that a number of modern statically typed languages have also decided not to include function overloading. i.e. Rust, Go, Ceylon.

I don't miss it. Overloading can get pretty messy.

On Wednesday, April 23, 2014 8:29:38 AM UTC+12, Broc Seib wrote:

[Greg Lowe]

Good point.

[Bob Nystrom]

On Tue, Apr 22, 2014 at 4:15 PM, 'Justin Fagnani <justin...@google.com>' via Dart Misc <mi...@dartlang.org> wrote:

The more accurate reason is that type annotations are not allowed to affect the behavior of the program. If the overloads were based on the annotations of the function parameters, it would violate that tenet.

Sure, but that's just semantic quibbling. Just don't refer to them as "type annotations" and you'd be free to dispatch on them at runtime without violating this principle.

That's exactly what the language does to sidestep the same issue in catch clauses. The "on Foo" isn't a "type annotation", it's an "on-catch clause" so it's totally fine and all of the type annotations are optional and don't mean anything I promise really trust me. :)

- bob

[Greg Lowe]

Also relevant:

"There will be no type based overloading in Dart. If you need a different variant of a method, create a method with a different name. This is what anyone using a dynmaic language does anyway and they are better for it. Even in language with mandatory types, type-based overloading is a bad idea, creating brittleness and ambiguity." - Gilad

https://code.google.com/p/dart/issues/detail?id=49#c8

[Peter Ahé]

Dart doesn't have overloading as it is our experience that overloading leads to confusion. Especially when you intend to override a method but accidentally overload it.

We think that optional arguments (named or not) are a better alternative.

Overloading is orthogonal to type annotations. You can overload based on number of arguments, but we weren't interested in having overloading.

In other words, rejecting overloading was not a consequence of the type system. It was a core principle we identified early in the design of Dart.

Cheers,

Peter

On Tuesday, April 22, 2014, Broc Seib <broc...@gmail.com> wrote:

Dart doesn't permit function overloading. Does anyone know the design decision/tradeoff behind this? Does this just simplify life for dart2js, or is there some other underlying limitation? Or was it just unwanted?

--

[Paul Brauner]

On Wed, Apr 23, 2014 at 1:15 AM, 'Justin Fagnani <justin...@google.com>' via Dart Misc <mi...@dartlang.org> wrote:

Right. The more accurate reason is that type annotations are not allowed to affect the behavior of the program. If the overloads were based on the annotations of the function parameters, it would violate that tenet.

Sure but there are places where type literals are not annotations in Dart (like in "x is Foo"). This could be one of those. For instance:

  Complex plus(x when double) => ...

  Complex plus(x when Complex) => ...

which would be sugar for:

  Complex plus(x) => (x is double) ? ... : ((x is Complex) ? ... : throw "no matching alternative")

or something like that.

I'm not saying it would be a good idea (I don't think it is), just that the rule that "type annotations are not allowed to affect the behavior of the program" doesn't prevent Dart from coming up with a syntax for multiple dispatch.

Paul

[Broc Seib]

Thanks Peter.