function return type special-syntax

[vtjnash]

proposal:

f() :> A declares that the result of f() must be object of type A (but using convert, not typeassert)

usage:

f() :> Float32 === 1.0f0
f() === 1
2 :> Float64 === 2.0

backward-compatible & default implementation:

f() :> A calls convert(A, f())

optional additional syntax

makes RT an optional 'hidden' parameter to the function, and allows the function to provide an optimized version using that information:

function f() :> RT::Number
  return 1
end
function g() :> RT
  return 1
end

final comments

• this is distinct from return type declarations #1090
• the :> operator is currently an unused, reserved keyword in the parser

[JeffBezanson]

This needs more detail, but my understanding is that this essentially provides return-type overloading by caller request?

So I could define

f() :> Int = 1
f() :> Float64 = 1.0

And these definitions will be somewhere in f's method table. Then there is a new primitive call_with_return_type(f, rt, args...) which looks up the definition f(args...) :> rt and calls it. :> in expression context is syntax for call_with_return_type. If no matching definition for the requested return type is found, convert is called instead.

Did I get that right?

[vtjnash]

i've left some of the implementation details for discussion. but I didn't initially intend to allow return-type overloading. the user has the option of dispatching to another function to add in that overloading, but this point would need more discussion first

f() :> Float64 = 1.0 would potentially be syntax to indicate the the return type of the function should be converted to Float64 (which I guess would make this a fix for #1090, although f() :: Float64 = 1.0 could also be added as the typeassert form)

[JeffBezanson]

I actually think the typeassert form of return type declaration is almost useless compared to the convert interpretation. With the convert form, you just write a type once and then don't have to worry about type instability. With typeassert, you still have to manually check every return point to make sure an error won't be thrown.

[StefanKarpinski]

That depends on if you prefer to have the compiler complain at you or just do what you want. We tend to prefer the latter around these parts, but there are languages where that's not the preference.

[JeffBezanson]

That's a fair point; if the declarations are just checks then you'd prefer those checks to be done as early as possible.

[tknopp]

I would vote for the convert behavior. The assertion would be handy while debugging performance issues but in "production code" one would (as Jeff said) have try/catch blocks around function calls that use return type annotations.

[vtjnash]

agreed, I'm much more excited about having clean syntax for return-type declaration and conversion than typeassert. just thought it would be worth mentioning the possibility of future design work

[JeffBezanson]

I think we will just do #1090.