On Thursday, October 13, 2016 at 1:00:21 PM UTC-7, Stefan Karpinski wrote: > > No, Function doesn't have signatures, arity or return type as part of its > type. The signature of a function is the union of its method signatures, > which is potentially very complicated. Type parameters are not > contravariant, so they can't be described without massively complicated > Julia's (already complicated) type system. Worse still, adding any form of > contravariance would almost certainly make important predicates like > subtype and type intersection undecidable. There are still things that > could be done to get some of the features that you probably want from > function types, but dispatching on the return type is unlikely to ever be > allowed. Two things that may happen are: >
Got it, thanks! I want method signatures for documentation, debugging, and as constraints or hints for the compiler, which are exactly what your two things provide. Are these are what you call 'interfaces' in your JuliaCon 2016 keynote, discussed here https://github.com/JuliaLang/julia/issues/6975? > 1. Constraining the type signature of a generic function, raising an error > if any method returns something that doesn't match: > > convert{T} :: (T, Any)-->T > > > or whatever syntax makes sense. This would implicitly mean that any call > to convert(T,x) would be translated to convert(T,x)::T so that we know > convert always returns the type one would expect for it. This is what I was > alluding to above. > > 2. Intersecting a function signature on an argument with a generic > function to extract a "sub-function" that will either behave the way we > expect it to or raise an error: > > function mysort!{T}(lt::(T,T)-->Bool, Vector{T}) > ... > > end > > > This would mean that any use like lt(a, b) in the function body would > implicitly be wrapped as lt(a::T, b::T)::Bool or something like that. This > extra type information could potentially allow the compiler to reason > better about the function's behavior even in cases where it otherwise can't > figure out that much. Of course, in the case that's already fast, we don't > need that information since the type of function calls can already be > completely inferred. > > Note that neither of these allow you to dispatch on the type of lt. >
