return type declarations

[JeffBezanson]

Provide this convenient shorthand:

function foo(x)::T
  ...
  return z
end

for this:

function foo(x)
  ret::T
  ...
  ret = z
  return ret
end

[johnmyleswhite]

Glad to hear you're planning to do this. Will we be able to specify that another function only accepts as inputs functions with specific types of returned values?

[StefanKarpinski]

Will we be able to specify that another function only accepts as inputs functions with specific types of returned values?

What you're talking about are function types, and I suspect we'll probably not support that, because covariance/contravariance/subtyping issues get pretty complicated and confusing. What kind use cases did you have in mind for this? We did intend to have this at one point, and the syntax String-->Int would be used for a method that takes Strings and returns Ints.

[johnmyleswhite]

The use cases are things like optimization functions: you want to insist that the function that purports to return a Hessian at a minimum is returning a Matrix. It's not so valuable that I'd worry about it if building support causes headaches.

[StefanKarpinski]

There will still always be run-time checks for things like that, and potentially compiler modes that can do inference and warn if you're doing something that looks wrong. But I'm not too sold on adding function types back in. They're a lot of trouble for little gain in a dynamic system like Julia. Of course, in Haskell you simply need them.

[johnmyleswhite]

Understood. I have no feel for these things, so I'm sure you're right.

[StefanKarpinski]

Well, I'm not at all sure I'm right, so there's that ;-)

[diegozea]

I agree with like davekong says on #1078

Uint8 + Uint8 = Int64

Looks too strange and unexpected.

I understand what Stefan says on that issue, and I think that something like type declaration of returns values can help. Because maybe its better promote into Int for calculation, but it's good gives to the user the expected type.
Uint8 + Uint8 needs to be a Uint8, even if for calculations are promoted to Int64 (unless you need more bits).

If you have and Array of Uint8 occupying N bytes on memory, in only and scalar multiplication you get an object consuming 4 times more memory...

Or in my case, I defined my bitstype of 8 bits and the following promotion rule [ I'm not sure of let be T, Int or Uint8 ]

-(x::NucleicAcid, y::NucleicAcid)   = int(x) - int(y)
promote_rule{T<:Number}(::Type{NucleicAcid}, ::Type{T}) = T

For simply get uppercase letters, I need to explicitly convert the output. But, if I set the promotion rule to NucleicAcid, I going to get a worse performance how Stefan point out before...

julia> seq = nt"ACTG"
4-element NucleicAcid Array:
 A
 C
 T
 G

julia> seq .+ 32
4-element Int64 Array:
  97
  99
 116
 103

julia> nucleotideseq(seq .+ 32) 
4-element NucleicAcid Array:
 a
 c
 t
 g

I know I can simply definite a function taking a NucleotideSeq and returning on the same type, and user are not going to see the explicit conversion... But. In general is not intuitive.

I'm not sure if return type declaration can be useful here.
...Maybe something like the next ?

promote_rule_IO(::TypeOne, ::TypeTwo) = TypeForOperate, TypeForOutputOnBinaryOperations 

[JeffBezanson]

In the case of arrays, I agree. See #1641 .

[johnmyleswhite]

Having spent more time working with optimization, I have to say that am now much more interested in one day adding the ability to do dispatch on functions typed by the combination of their input types and their return types. It would be nice to have the ability to write separate definitions for:

• derivative(f::Real -> Real)
• derivative(f::Real -> Vector{Real})
• derivative(f::Vector{Real} -> Real)
• derivative(f::Vector{Real} -> Vector{Real})

[timholy]

This is why in all my optimization routines, I pass the gradient into the objective function. Once it's an argument, you can do dispatch on it.

[rsofaer]

One reason I'd like to be able to specify return types for functions is that it would improve looking at functions in the REPL. With return types I can much more easily tell at a glance what the functions in the list given by * do.

[evanrinehart]

If anything this would add a lot to the self-documenting nature of a functions source code. I really miss the type of the return value from the source / documentation of basically every other popular dynamic system. It would also help in mentally planning the body of the function while writing it. Would discourage implementation of annoying behavior like PHP's tendency to return a NULL, or a false, or a normal value. Such behavior could totally be made explicit to the reader with the union types. Looking forward to this feature!