I don’t really understand this one for a few reasons:
- Dispatching a method on interfaces as if they were types (the supertype of all iterators being a not very helpful
Any) will cause brittle ambiguity issues like multiple supertypes would. Multiple Holy traits evade such issues by dedicating a trait function to check each trait set, and you can only have 1 trait per set. The trait function call follows type-based dispatch, so traits are not independent of types or dispatch limitations. Assuming you’re not talking about the iteration-reliantlast(x, n)methods,last(x)depends onlastindex, which is part of the indexing interface, not the iteration interface. Those often come together but you can have either alone.How would a fallbacklasteven work for iterators or indexables? Neither necessarily have a last element and could need to error upon alast(x)call, which will just work iflastindexisn’t implemented for the concrete type. The only change I could see interface/trait dispatch make is turning aMethodErrorforlastindexinto aMethodErrorforlast.- Upon rereading, it is clearer that you intended to implement a
lastmethod for iterables in addition to the method for indexables, and neither needs to be always successful. Unfortunately, dispatching on multiple orthogonal interfaces would have the same ambiguity issues as multiple supertypes, for example does an iterable and indexable input dispatch the call to the iterable method or the indexable method? The approach that comes to mind is to modify the existing method to check for the quicker indexing sense of last element then the slower iteration sense of last element (which has theHasLengthandHasShape{N}traits of theIteratorSizetrait set). I think this could be done by checkinghasmethodonlastindex+getindexthenlength+iterate, and if Tricks.jl is right, this can occur at compile-time and be invalidated by method changes in v1.10. I have not verified this behavior orapplicable’s, nor do I know exactly what builtins, intrinsics, and tfuncs are.