Strict typing and restricting types in a method's signature

[ChrisRackauckas]

@bpr

Excellent examples! But let me ask a question here. Say you’d written your iterative solver over matrices with over-specific types. Do you really think it’s unlikely that you wouldn’t see how you could generalize the types?

If I’m understanding the question properly, the problem is moreso that you can’t have multiple inheritance so in some cases you can’t easily generalize the types. Sometimes what you want to support is an Operator type which could only exist in some library. If you want to <:Operator, then you have to have the library which defines Operator as a dependency. So you have to make a choice:

1. Hope that everyone subtypes the right things (i.e. make your iterative solver work on Union{Matrix,Function} and tell other libraries they have to subtype Function with their weird overloaded types).
2. Not try to support any non-Base type.
3. Leave your function untyped.

For library building, leaving the function as untyped (duck-typing) tends to be the preferred option since it generalizes the applicability. Of course, there are the drawbacks you’ve mentioned (the errors are more obscure since they will always attempt to use the function, and the documentation won’t be as specific), but…

@bpr

For your personal example, all things which define +, -, /, *, and sqrt support an interface or trait. If you can define such a trait in your language, that’s your type constraint. But I’m sure you know that already

Yes, the “true” answer I think will come from traits. For now, interfaces are informal. However, we have setup in JuliaDiffEq using SimpleTraits.jl (macros for Holy traits) where traits are automatically applied when certain dispatches are implemented (and they are inferred by the compiler), and so ImplementsIterator dispatches are possible using this kind of thing, i.e. you have make a function

f(x::::ImplementsIterator) = ...

and everything about the traits are known at compile time (so no dynamic dispatch).

I think this form of trait-constraints for documentation/errors + automatically/dynamically applied traits (but when the function compiles, so it compiles to fully-performant code as seen by @code_llvm) for ease of use and “auto-extensability” is the middleground. Of course, Julia doesn’t have a base implementation for traits yet so this is still experimental (but very useful! I’m not sure it plays well with pre-compilation either), but I see a bright future.