[swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

[Jonathan Hull]

> On Jun 12, 2016, at 8:31 PM, Dave Abrahams <dabrahams at apple.com> wrote:
> 
> 
> 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.

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,
>> 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

Thank you, much appreciated.


> 
> HTH,
> -- 
> Dave
>