Traits, functions, defaults

[andyferris]

I'm excited someone is looking into this. :)

Apart from the design of a formal array interface (definition of traits such as mutability) I was wondering what the "meta" design decisions about how the traits are defined and discovered are.

Base has used "Tim Holy" traits in a number of places to help with e.g. iteration performation. I note the initial version here uses an ismutable function that returns a constant value.

I was wondering what the trade-offs are between type traits vs functions (and constant propagation / branch pruning) might be and what would be preferable. Are traits properties of types or of instances?

Also whether one wants "defaults" like ismutable(::AbstractArray) = true or false are desirable, or something to avoid. (One thing I like about the current system is one can create a simple abstract array with about 2 or 3 method definitions).

[ChrisRackauckas]

I was wondering what the trade-offs are between type traits vs functions (and constant propagation / branch pruning) might be and what would be preferable. Are traits properties of types or of instances?

My definition of a trait is that is a function on types whose result is deducible solely from type information. The main result of this is that the result of such functions are known at compile time. Whether to rely on constant prop or not is something I'm not entirely sure about right now, but in v1.0 we don't necessarily need to return a type in order for the function call to and branches to elide.

Also whether one wants "defaults" like ismutable(::AbstractArray) = true or false are desirable, or something to avoid. (One thing I like about the current system is one can create a simple abstract array with about 2 or 3 method definitions).

For this, I need a working system to be using it in DiffEq. When we consider transitioning parts over to Base, we can discuss the defaults of each trait in detail. But for now, the defaults are what lead to succinct usable results.