I was looking at the COM module of Winim and came across what looks to be (to my newbie eye) procedure overloading by return type:
converter variantConverter*(x: variant): string = fromVariant[string](x)
converter variantConverter*(x: variant): cstring = fromVariant[cstring](x)
converter variantConverter*(x: variant): mstring = fromVariant[mstring](x)
converter variantConverter*(x: variant): wstring = fromVariant[wstring](x)
Does Nim allow this (I couldn't get it to work, but I may be doing something wrong)?
I never understood why Nim doesn't allow this. :(
If you want to keep the same name and use overloading, one option is to use a var argument instead of return. This works:
proc myBirthday(n: var int) =
n = 372297600
proc myBirthday(s: var string) =
s = "October 19, 1981"
var s : string; myBirthday s
var n : int; myBirthday n
echo "Human Date: ", s
echo "Unix Time: ", n
C++, Java, Dlang, C# etc don't allow this either... But IMSO (in my stupid option) it would still be a good idea.
I thought Nim's philosophy was to not make the programmer jump through hoops (ex. namespace prefixes) to make ambiguity impossible, but to have the compiler figure it out if possible, or have an error if ambiguity actually exists. Outright disabling overloading by return type is an inconsistency with this philosophy.
Overloading by return type would only work when assigning to something that has a declared type, otherwise (if using discard or expecting type inference) you'd get an error.
Overloading by return type would only work when assigning to something that has a declared type, otherwise (if using discard or expecting type inference) you'd get an error.
That's what araq meant with defeating Nim's type inference.
In my case, I too don't like about return type overloading, when I look at function/procedure, the first thing I look is the return type. If it's overloaded with another type, it'll confuse me a lot.
Also, type inference helpful when there's a case you don't have to import that specific type but still use that as argument for another functions.
Furthermore, just make a template or macro to resolve it. Nim already flexible enough and with those, how far the flexibility is in your own.
C++, Java, Dlang, C# etc don't allow this either... But IMSHO (in my humble stupid option) it would still be a good idea.
Ada allows overloading on return type, but doesn't have type inference or implicit converters, which complicate things quite a bit. I get the impression that Araq is quite familiar with Ada, so I think the omission of this feature is a well considered decision, not an oversight on his part. I'm a fan of the feature in Ada, but I think the right decision was made for Nim.
The top-rated answer to this SO question is a very interesting read. Some teaser quotes:
Overloading by return type is possible and is done by some modern languages.
Two of the languages I regularly (ab)use overload by return type: Perl and Haskell.
Haskell takes the other approach, namely to not have side effects. It also has a strong type system [...]