Nim: overloading on return value

[PavelVozenilek]

The compiler accepts when there are functions overloaded by return value only

proc foo() : int = 1                       # this compiles
proc foo() : string = "aaa"

However trying to use them fails even when there's no ambiguity

proc foo() : int = 1
proc foo() : string = "aaa"
var x : int = foo()       # fails to compile in 0.9.3

Perhaps clear cases could be allowed. It may be useful e.g. when returing more precise time value.:

proc now() : int = ...
proc now() : timeval = ...
proc now() : timeval_with_nanosecond_precision = ...

var precision_in_seconds : int = now()

[Varriount]

Return type inference is a planned feature, though I don't know how Araq has planned it to work.

[zah]

Yes, this is a planned feature and it will work exactly as the provided examples here. Other supported forms will be:

var x = string(foo())

proc takesString(x: string) = ...
takesString(foo())

No ETA yet.

[ozra]

Return type overloading is something I really miss in C++ and other langs, would be really handy in specific situations!

[mdeck]

Want

[hcorion]

Just ran into this issue, would appreciate it.

[dom96]

While this would be nice, it's not on our roadmap for v1.

[Araq]

Not gonna happen soon and I dislike it. I don't want APIs that dictate me to write let x: SomeType = overloadedByReturnType.

[zah]

The classic use case of return-type overloading is not let x: Foo = bar(), but rather foo(overloadedByReturnType()) or object.field = overloadedByReturnType().

Overloading by return type is mostly useful for generic algorithms that can populate any kind of Dictionary or Container for example. Any alternative allowing similar flexibility (by encoding the desired type in an extra parameter) would be just as verbose as the example you wanted to avoid.

[Araq]

Any alternative allowing similar flexibility (by encoding the desired type in an extra parameter) would be just as verbose as the example you wanted to avoid.

Maybe, maybe not. Depends on the concrete alternative. And even if the alternative is "just as verbose" it might have the advantage of not being yet another language feature, we need to document, test, support and all of our users need to know about and understand.