# Strict typing and restricting types in a method's signature

**URL:** https://discourse.julialang.org/t/strict-typing-and-restricting-types-in-a-methods-signature/645
**Category:** General Usage
**Created:** [November 29, 2016, 3:21pm UTC](https://discourse.julialang.org/t/strict-typing-and-restricting-types-in-a-methods-signature/645 "2016-11-29T15:21:54Z")
**Posts on this page:** 1
**Showing post:** 17

<div class="post-metadata">

### Author: ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)
#### Post date: [November 30, 2016, 12:15am UTC](https://discourse.julialang.org/t/strict-typing-and-restricting-types-in-a-methods-signature/645/17 "2016-11-30T00:15:40Z")

</div>

> [@Meaning of {T}](https://discourse.julialang.org/t/meaning-of-t/623/22):
>
> 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…

> [@Meaning of {T}](https://discourse.julialang.org/t/meaning-of-t/623/22):
>
> 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](http://docs.julialang.org/en/release-0.5/manual/interfaces/). However, [we have setup in JuliaDiffEq using SimpleTraits.jl (macros for Holy traits)](https://discourse.julialang.org/t/how-to-find-if-a-method-is-implemented-for-an-interface/636/5) 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

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

---

_[View the full topic](https://discourse.julialang.org/t/strict-typing-and-restricting-types-in-a-methods-signature/645)._