I feel like each post starts over from scratch with no after-v1.0 end goal in sight
My personal understanding (and maybe I’m wrong!) is that allowing trait-based multiple dispatch has been discussed over time as the likely “Julia multiple inheritance” of the future. The subtyping algorithm needed to do this appears feasible (e.g. in Traitor.jl) so unless I missed something important I don’t think that side of things will hold this up. Multiple dispatch is Julia’s great strength - making it stronger would be killer, and I don’t see a good reason for not getting around to this (eventually).
IMO this should let us define and adhere to interfaces/concepts in a clear way (with the usual caveats that @TomasPuverle discussed about the implications of an interface changing - but generally Julia has done a decent job with deprecation messages). Of course this is just my opinion, and I can’t see the future, but my suggestion would be patient and see what is missing (if anything) in the post-traits world - traits would impact many things on Stefan’s list.
Regarding mix-ins, I’d speculate that trait-based interfaces would be function-based not field-based, so you would have to specify some small numbers of setters and getters for each interface you support instead of using particular field names (while I hate the overhead of setter/getters in C++/Java/etc, take a complex interface like
AbstractArray in Julia and note that one has to define just one static trait (
LinearSlow), one property (
size), one getter method (
getindex) and one setter method (
setindex!). Amazing, but that’s what we get out of multiple dispatch (and single-trait “Tim Holy trait trick”), so I’d expect similar for other interfaces).
I’m not sure if speculative future features should go in the docs (depending on their level of likelihood and proximity, I suppose).