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:
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
If that error is being thrown to handle what you consider to be a
programming error, that is the moral equivalent of a trap.
Agreed. In this case the error is thrown when two different user inputs don’t match types, and it results in a user facing error. It basically functions as input validation.
It seems to me that Swift has four ways of handling failure:
1) Disallow it entirely
2) Trap (marked with !)
3) Throw (marked with try)
4) Return nil (marked with ?)
It seems to me that the Swift-y™ way to handle this is to disallow it until the programmer chooses the most appropriate of the other three options.
It may be that trapping is the right thing to do the majority of the time, but I definitely have use-cases where returning nil is the correct option.
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,
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
Thank you, much appreciated.
On Jun 12, 2016, at 8:31 PM, Dave Abrahams <firstname.lastname@example.org> wrote:
on Sat Jun 11 2016, Jonathan Hull <jhull-AT-gbis.com> wrote: