on Sat Jun 11 2016, Jonathan Hull <jhull-AT-gbis.com> wrote: >> If your code has many manual type erasing wrappers corresponding to >> protocols with associated types and/or Self requirements that also never >> have to trap type mismatches, that would certainly be instructive >> empirical data. Would you care to share the protocols and wrappers you >> are talking about? > This code is a bit embarrassing (I wrote most of it as I was still > learning Swift), but if it is helpful I will share: > https://gist.github.com/jonhull/639e756ad5228348f93f40f06169588c > > It doesn’t trap anywhere (that I know about). Some of the code which > calls it does throw an error in the case of mismatched types (but it > doesn’t/shouldn't crash).
If that error is being thrown to handle what you consider to be a programming error, that is the moral equivalent of a trap. > Most functions which use it are generic on the associatedType. > > It does work fairly well though (even on the AppleWatch). The main > issue is that I have no way to persist the values which have been > drawn into the type-erased world (or even the value-type world, > really). > > Also, if anyone has a better way to write the type erasing wrapper, I > would love to hear it. These are very memory intensive… It looks like you could make some gains by, instead of storing a closure for each operation, using a base class with a method for each operation, per the box types in https://github.com/apple/swift/blob/master/stdlib/public/core/ExistentialCollection.swift.gyb HTH, -- Dave _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution