Yes, that's essentially it – except that since we haven't converged on a
particular design, it's hard to say exactly what interfaces are at this
point. But yes, it's something that provides a first class representation
of some protocol/interface.

On Mon, Oct 17, 2016 at 11:33 AM, Brian Rogoff <> wrote:

> 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
>> 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.

Reply via email to