<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 9, 2016, at 11:42 AM, Dave Abrahams <<a href="mailto:dabrahams@apple.com" class="">dabrahams@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">on Thu Jun 09 2016, Matthew Johnson <</span><a href="http://matthew-at-anandabits.com/" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">matthew-AT-anandabits.com</a><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">> wrote:</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class="">On Jun 9, 2016, at 9:55 AM, Dave Abrahams <<a href="mailto:dabrahams@apple.com" class="">dabrahams@apple.com</a>> wrote:<br class=""><br class=""><br class="">on Wed Jun 08 2016, Matthew Johnson <<a href="http://matthew-at-anandabits.com/" class="">matthew-AT-anandabits.com</a><span class="Apple-converted-space"> </span><<a href="http://matthew-at-anandabits.com/" class="">http://matthew-at-anandabits.com/</a>>> wrote:<br class=""><br class=""></blockquote><br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class="">On Jun 8, 2016, at 1:33 PM, Dave Abrahams <<a href="mailto:dabrahams@apple.com" class="">dabrahams@apple.com</a>> wrote:<br class=""><br class=""><br class="">on Tue Jun 07 2016, Matthew Johnson <<a href="http://matthew-at-anandabits.com/" class="">matthew-AT-anandabits.com</a>> wrote:<br class=""><br class=""></blockquote><br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class="">On Jun 7, 2016, at 9:15 PM, Dave Abrahams <<a href="mailto:dabrahams@apple.com" class="">dabrahams@apple.com</a>> wrote:<br class=""><br class=""><br class="">on Tue Jun 07 2016, Matthew Johnson <<a href="http://matthew-at-anandabits.com/" class="">matthew-AT-anandabits.com</a><span class="Apple-converted-space"> </span><<a href="http://matthew-at-anandabits.com/" class="">http://matthew-at-anandabits.com/</a>>> wrote:<br class=""><br class=""></blockquote><br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class="">On Jun 7, 2016, at 4:13 PM, Dave Abrahams via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""><br class="">on Tue Jun 07 2016, Matthew Johnson <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></blockquote><br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class="">, but haven't realized<br class="">that if you step around the type relationships encoded in Self<br class="">requirements and associated types you end up with types that appear to<br class="">interoperate but in fact trap at runtime unless used in exactly the<br class="">right way.<br class=""></blockquote><br class="">Trap at runtime? How so? Generalized existentials should still be<br class="">type-safe. <br class=""></blockquote><br class="">There are two choices when you erase static type relationships:<br class=""><br class="">1. Acheive type-safety by trapping at runtime<br class=""><br class="">FloatingPoint(3.0 as Float) + FloatingPoint(3.0 as Double) // trap<br class=""><br class="">2. Don't expose protocol requirements that involve these relationships,<br class="">which would prevent the code above from compiling and prevent<br class="">FloatingPoint from conforming to itself.<br class=""><br class=""><blockquote type="cite" class="">Or are you talking about the hypothetical types / behaviors people<br class="">think they want when they don’t fully understand what is happening...<br class=""></blockquote><br class="">I don't know what you mean here. I think generalized existentials will<br class="">be nice to have, but I think most people will want them to do something<br class="">they can't possibly do.<br class=""></blockquote><br class="">Exactly. What I meant is that people think they want that expression<br class="">to compile because they don’t understand that the only thing it can do<br class="">is trap. I said “hypothetical” because producing a compile time error<br class="">rather than a runtime trap is the only sane thing to do. Your comment<br class="">surprised me because I can’t imagine we would move forward in Swift<br class="">with the approach of trapping.<br class=""></blockquote><br class="">I would very much like to be able to create instances of “Collection<br class="">where Element == Int” so we can throw away the wrappers in the stdlib.<br class="">That will require some type mismatches to be caught at runtime via<br class="">trapping.<br class=""></blockquote><br class="">For invalid index because the existential accepts a type erased index?<br class=""></blockquote><br class="">Exactly.<br class=""><br class=""><blockquote type="cite" class="">How do you decide where to draw the line here? It feels like a very<br class="">slippery slope for a language where safety is a stated priority to<br class="">start adopting a strategy of runtime trapping for something as<br class="">fundamental as how you expose members on an existential.<br class=""></blockquote><br class="">If you don't do this, the alternative is that “Collection where Element<br class="">== Int” does not conform to Collection. <br class=""></blockquote><br class="">This isn’t directly related to having self or associated type<br class="">requirements. It is true of all existentials. <br class=""></blockquote><br class="">That is just an implementation limitation today, IIUC. What I'm talking<br class="">about here would make it impossible for some to do that.<br class=""></blockquote><br class="">If it is just an implementation limitation I am happy to hear that.<br class=""><br class=""><blockquote type="cite" class=""><br class=""><blockquote type="cite" class="">If that changes for simple existentials and generalized existentials<br class="">expose all members (as in the latest draft of the proposal) maybe it<br class="">will be possible for all existentials to conform to their protocol.<br class=""></blockquote><br class="">Not without introducing runtime traps. See my “subscript function”<br class="">example.<br class=""></blockquote><br class=""><blockquote type="cite" class=""><br class=""><blockquote type="cite" class=""><br class=""><blockquote type="cite" class="">That's weird and not very<br class="">useful. You could expose all the methods that were on protocol<br class="">extensions of Collection on this existential, unless they used<br class="">associated types other than the element type. But you couldn't pass the<br class="">existential to a generic function like<br class=""><br class="">func scrambled<C: Collection>(_ c: C) -> [C.Element]<br class=""><br class=""><blockquote type="cite" class="">IMO you should *have* to introduce unsafe behavior like that manually.<br class=""></blockquote><br class="">Collection where Element == Int & Index == *<br class=""><br class="">?<br class=""></blockquote><br class="">I didn’t mean directly through the type of the existential.<br class=""></blockquote><br class="">My question is, why not? That is still explicit.<br class=""></blockquote><br class="">It’s not explicit in the sense that nobody wrote `fatalError` or<br class="">similar in their code. It’s too easy to write something like that<br class="">without realizing that it introduces the possibility of a crash. If<br class="">we adopt syntax like that to introduce an existential that introduces<br class="">traps we should at least require members that can be trap to be<br class="">invoked using a `!` suffix or something like that to make it clear to<br class="">users that a trap will happen if they are not extremely careful when<br class="">using that member.<br class=""><br class="">More generally though, I don’t want the rules of the language to be<br class="">written in a way that causes the compiler to synthesize traps in such<br class="">a general way.<br class=""><br class="">The existential should not introduce a precondition that isn’t already<br class="">present in the semantics of the protocol itself. If the semantics of<br class="">the protocol do not place preconditions on arguments beyond their type<br class="">(such as “must be a valid index into this specific instance”) the<br class="">compiler should not allow the existential to conform if a trap is<br class="">required in some circumstances. That is a new precondition and<br class="">therefore the existential does not actually fulfill the requirements<br class="">of the protocol.<br class=""><br class="">I could *maybe* live with a solution where protocol requirements are<br class="">marked as trapping, etc depending on the specific argument received at<br class="">runtime. This is a total straw man syntax, but maybe `IndexableBase`<br class="">would declare the subscript `@trapping` (probably something different<br class="">but I hope this communicates the idea). This alerts users to the fact<br class="">that they need to be extra careful - not any value of `Self.Index` is<br class="">valid and you can get a crash if you’re not careful.<br class=""><br class="">Having this semantic explicit in the definition of the protocol opens<br class="">the door to maybe considering an existential synthesized by the<br class="">compiler that traps because it doesn’t introduce a new precondition<br class="">that wasn’t already present in the protocol.<br class=""><br class="">I would want to give consideration to specific details of a proposal<br class="">along these lines before deciding how I feel about it, but I have a<br class="">more open mind to this approach than introducing traps not present in<br class="">the preconditions of the protocol.<br class=""><br class="">/// You can subscript a collection with any valid index other than the<br class="">/// collection's end index. The end index refers to the position one past<br class="">/// the last element of a collection, so it doesn't correspond with an<br class="">/// element.<br class="">///<br class="">/// - Parameter position: The position of the element to access. `position`<br class="">/// must be a valid index of the collection that is not equal to the<br class="">/// `endIndex` property.<br class="">@trapping public subscript(position: Self.Index) -> Self._Element { get }<br class=""><br class=""><blockquote type="cite" class=""><br class=""><blockquote type="cite" class="">One obvious mechanism for introducing unsafe behavior is to write<br class="">manual type erasure wrappers like we do today.<br class=""><br class="">Another possibility would be to allow extending the existential type<br class="">(not the protocol). This would allow you to write overloads on the<br class="">Collection existential that takes some kind of type erased index if<br class="">that is what you want and either trap if you receive an invalid index<br class="">or better (IMO) return an `Element?`. I’m not sure how extensions on<br class="">existentials might be implemented, but this is an example of the kind<br class="">of operation you might want available on it that you wouldn’t want<br class="">available on all Collection types.<br class=""><br class=""><blockquote type="cite" class=""><br class=""><blockquote type="cite" class="">Collection indices are already something that isn’t fully statically<br class="">safe so I understand why you might want to allow this. <br class=""></blockquote><br class="">By the same measure, so are Ints :-)<br class=""><br class="">The fact that a type's methods have preconditions does *not* make it<br class="">“statically unsafe.”<br class=""></blockquote><br class="">That depends on what you mean by safe. Sure, those methods aren’t<br class="">going corrupt memory, but they *are* going to explicitly and<br class="">intentionally crash for some inputs. That doesn’t qualify as “fully<br class="">safe” IMO.<br class=""></blockquote><br class="">Please pick a term other than “unsafe” here; it's not unsafe in the<br class="">sense we mean the word in Swift. It's safe in exactly the same way that<br class="">array indexes and integers are. When you violate a precondition, it<br class="">traps.<br class=""></blockquote><br class="">I am happy to use any word you like here.<br class=""><br class="">Can you clarify what you mean by the word safe in Swift? It doesn’t<br class="">appear to be limited to memory safety in the public about page<br class=""><a href="https://swift.org/about/" class="">https://swift.org/about/</a><span class="Apple-converted-space"> </span><<a href="https://swift.org/about/" class="">https://swift.org/about/</a>>:<br class=""></blockquote><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">I mean memory- and type-safe.</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">Safe. The most obvious way to write code should also behave in a safe<br class="">manner. Undefined behavior is the enemy of safety, and developer<br class="">mistakes should be caught before software is in production. Opting for<br class="">safety sometimes means Swift will feel strict, but we believe that<br class="">clarity saves time in the long run.<br class=""><br class="">Safety<br class=""><br class="">Swift was designed from the outset to be safer than C-based languages,<br class="">and eliminates entire classes of unsafe code. Variables are always<br class="">initialized before use, arrays and integers are checked for overflow,<br class="">and memory is managed automatically. Syntax is tuned to make it easy<br class="">to define your intent — for example, simple three-character keywords<br class="">define a variable (var) or constant (let).<br class=""><br class="">Another safety feature is that by default Swift objects can never be<br class="">nil, and trying to make or use a nil object will results in a<br class="">compile-time error. This makes writing code much cleaner and safer,<br class="">and prevents a common cause of runtime crashes. However, there are<br class="">cases where nil is appropriate, and for these situations Swift has an<br class="">innovative feature known as optionals. An optional may contain nil,<br class="">but Swift syntax forces you to safely deal with it using ? to indicate<br class="">to the compiler you understand the behavior and will handle it safely.<br class=""><br class="">This positioning statement makes it appear as if preventing common<br class="">causes of crashes falls within the meaning of safe that Swift is<br class="">using. Having existentials introduce new preconditions and traps when<br class="">they are not met does not seem aligned with that goal IMO.<br class=""></blockquote><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Static typing “increases safety,” in the casual sense. That doesn't</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">mean that an operation that traps on a failed precondition check is</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">“unsafe.”</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class="">The user doesn't do anything “manual” to introduce that trapping<br class="">behavior for integers. Preconditions are a natural part of most types.<br class=""></blockquote><br class="">The user doesn’t, but isn’t the overflow trap implemented in the<br class="">standard library? <br class=""></blockquote><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Whether it is or is not is an implementation detail.</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">Regardless, this is a specific case that has been given explicit<br class="">design attention by humans. The precondition is designed, not<br class="">introduced by compiler rules that haven’t considered the specific case<br class="">in question.<br class=""><br class=""><blockquote type="cite" class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class="">But I don’t think having the language's existentials do this<br class="">automatically is the right approach. Maybe there is another<br class="">approach that could be used in targeted use cases where the less<br class="">safe behavior makes sense and is carefully designed.<br class=""></blockquote><br class="">Whether it makes sense or not really depends on the use-cases. There's<br class="">little point in generalizing existentials if the result isn't very useful.<br class=""></blockquote><br class="">Usefulness depends on your perspective. <br class=""></blockquote><br class="">Of course. As I've said, let's look at the use cases.<br class=""></blockquote><br class="">Agree. We can consider those in depth when the time comes to ramp up<br class="">discussion of Austin’s proposal.<br class=""><br class=""><blockquote type="cite" class=""><br class=""><blockquote type="cite" class="">I have run into several scenarios where they would be very useful<br class="">without needing to be prone to crashes when used incorrectly. One<br class="">obvious basic use case is storing things in a heterogenous collection<br class="">where you bind .<br class=""></blockquote><br class="">bind what?<br class=""></blockquote><br class="">Sorry, I must have gotten distracted and not finished that paragraph.<br class="">I meant to say bind the associated types that are necessary for your<br class="">use case. Sometimes you bind *all* of the associated types to<br class="">concrete types and the protocol has no `Self` requirements. In that<br class="">case there is no trouble at all in conforming the type-erased<br class="">“existential" to the protocol itself. Austin’s proposal would<br class="">eliminate the need to manually write these “existentials” manually.<br class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><br class=""><blockquote type="cite" class="">The way to find out is to take a look at the examples we currently have<br class="">of protocols with associated types or Self requirements and consider<br class="">what you'd be able to do with their existentials if type relationships<br class="">couldn't be erased. <br class=""><br class="">We have known use-cases, currently emulated in the standard library, for<br class="">existentials with erased type relationships. *If* these represent the<br class="">predominant use cases for something like generalized existentials, it<br class="">seems to me that the language feature should support that. Note: I have<br class="">not seen anyone build an emulation of the other kind of generalized<br class="">existential. My theory: there's a good reason for that :-).<br class=""></blockquote><br class="">AFAIK (and I could be wrong) the only rules in the language that<br class="">require the compiler to synthesize a trap except using a nil IUO, `!`<br class="">on a nil Optional, and an invalid `as` cast . These are all<br class="">syntactically explicit unsafe / dangerous operations. All other traps<br class="">are in the standard library (array index, overflow, etc). Most<br class="">important about all of these cases is that they have received direct<br class="">human consideration.<br class=""></blockquote><br class="">There is no distinction in the user model between what might be<br class="">synthesized by the language and what appears on standard library types.<br class=""></blockquote><br class="">Maybe I shouldn’t have made that distinction. <br class=""><br class="">The point I am trying to emphasize is that each of these are special<br class="">cases that have received direct human consideration. The potential<br class="">for a trap is not introduced by language rules that apply to<br class="">user-defined constructs in without consideration of the specific<br class="">details of that construct.<br class=""><br class=""><blockquote type="cite" class=""><br class=""><blockquote type="cite" class="">Introducing a language (not library) mechanism that exposes members on<br class="">generalized existentials in a way that relies on runtime traps for<br class="">type safety feels to me like a pretty dramatic turn agains the stated<br class="">priority of safety. It will mean you must understand exactly what is<br class="">going on and be extremely careful to use generalized existentials<br class="">without causing crashes. This will either make Swift code much more<br class="">crashy or will scare people away from using generalized existentials<br class="">(and maybe both). <br class=""></blockquote><br class="">I don't accept either of those statements without seeing some analysis<br class="">of the use-cases. For example, I don't believe that AnyCollection et al<br class="">are particularly crash-prone. The likelihood that you'll use the wrong<br class="">index type with a collection is very, very low. I'm less certain of<br class="">what happens with Self requirements in real cases.<br class=""></blockquote><br class="">But again, I believe this is an exceptional case as the precondition<br class="">is explicitly stated in the semantics of the protocol.<br class=""></blockquote><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">IIUC, it has been cited by Doug as the exemplar of the</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">predominantly-requested case by a 10:1 ratio!</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""></div></blockquote><div><br class=""></div><div>In terms of forming the existential, storing it in variables, accepting arguments of that type, etc yes. I don’t know how many of those requests expect it to conform to the protocol and expect to be able to use it in generic code constrained to the protocol.</div><br class=""><blockquote type="cite" class=""><div class=""><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">IMO the burden of proof should be on the side that proposes a<br class="">mechanism to introduce traps, not the side that proposes avoiding<br class="">them.<br class=""></blockquote><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">If you really want to make this about sides and burdens, the burden of</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">proof always rests with the side proposing to extend the language. We</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">shouldn't be making changes without understanding how they will play out</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">in real use-cases.</span></div></blockquote><div><br class=""></div><div>I agree with this. But if we are discussing two different options for extending the language I think the option that doesn’t introduce crashes should be preferred without pretty compelling reasons to choose the option that can introduce crashes.</div><br class=""><blockquote type="cite" class=""><div class=""><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><blockquote type="cite" class="">Neither of those outcomes is good.<br class=""><br class="">Collection indices are a somewhat special case as there is already a<br class="">strong precondition that people are familiar with because it would be<br class="">too costly to performance and arguably too annoying to deal with an<br class="">Optional result in every array lookup. IMO that is why the library is<br class="">able to get away with it in the current type erased AnyCollection.<br class="">But this is not a good model for exposing any members on an<br class="">existential that do not already have a strong precondition that causes<br class="">a trap when violated.<br class=""><br class="">I think a big reason why you maybe haven’t seen a lot of examples of<br class="">people writing type erased “existentials" is because it is a huge pain<br class="">in the neck to write this stuff manually today. People may be<br class="">designing around the need for them. I haven’t seen a huge sampling of<br class="">type erased “existentials" other people are writing but I haven’t<br class="">written any that introduce a trap like this. The only traps are in<br class="">the “abstract" base class whose methods will never be called (and<br class="">wouldn’t even be implemented if they could be marked abstract).<br class=""><br class="">What specific things do you think we need to be able to do that rely<br class="">on the compiler synthesizing a trap in the way it exposes the members<br class="">of the existential?<br class=""></blockquote><br class="">I don't know. I'm saying, I don't think we understand the use-cases<br class="">well enough to make a determination.<br class=""></blockquote><br class="">That’s fair. I agree that use cases should be carefully considered. <br class=""><br class=""><blockquote type="cite" class=""><br class=""><blockquote type="cite" class="">Here are a few examples from Austin’s proposal that safely use<br class="">existential collections. I don’t understand why you think this<br class="">approach is insufficient. Maybe you could supply a concrete example<br class="">of a use case that can’t be written with the mechanism in Austin’s<br class="">proposal.<br class=""><br class=""><a href="https://github.com/austinzheng/swift-evolution/blob/az-existentials/proposals/XXXX-enhanced-existentials.md#associated-types-and-member-exposure" class="">https://github.com/austinzheng/swift-evolution/blob/az-existentials/proposals/XXXX-enhanced-existentials.md#associated-types-and-member-exposure</a><span class="Apple-converted-space"> </span><<a href="https://github.com/austinzheng/swift-evolution/blob/az-existentials/proposals/XXXX-enhanced-existentials.md#associated-types-and-member-exposure" class="">https://github.com/austinzheng/swift-evolution/blob/az-existentials/proposals/XXXX-enhanced-existentials.md#associated-types-and-member-exposure</a>> <<a href="https://github.com/austinzheng/swift-evolution/blob/az-existentials/proposals/XXXX-enhanced-existentials.md#associated-types-and-member-exposure" class="">https://github.com/austinzheng/swift-evolution/blob/az-existentials/proposals/XXXX-enhanced-existentials.md#associated-types-and-member-exposure</a><<a href="https://github.com/austinzheng/swift-evolution/blob/az-existentials/proposals/XXXX-enhanced-existentials.md#associated-types-and-member-exposure" class="">https://github.com/austinzheng/swift-evolution/blob/az-existentials/proposals/XXXX-enhanced-existentials.md#associated-types-and-member-exposure</a>>><br class=""><br class="">let a : Any<Collection><br class=""><br class="">// A variable whose type is the Index associated type of the underlying<br class="">// concrete type of 'a'.<br class="">let theIndex : a.Index = ...<br class=""><br class="">// A variable whose type is the Element associated type of the underlying<br class="">// concrete type of 'a'.<br class="">let theElement : a.Element = ...<br class=""><br class="">// Given a mutable collection, swap its first and last items.<br class="">// Not a generic function.<span class="Apple-converted-space"> </span><br class="">func swapFirstAndLast(inout collection: Any<BidirectionalMutableCollection>) {<br class=""> // firstIndex and lastIndex both have type "collection.Index"<br class=""> guard let firstIndex = collection.startIndex,<br class=""> lastIndex = collection.endIndex?.predecessor(collection) where lastIndex != firstIndex else {<br class=""> print("Nothing to do")<br class=""> return<br class=""> }<br class=""><br class=""> // oldFirstItem has type "collection.Element"<br class=""> let oldFirstItem = collection[firstIndex]<br class=""><br class=""> collection[firstIndex] = collection[lastIndex]<br class=""> collection[lastIndex] = oldFirstItem<br class="">}<br class=""><br class="">var a : Any<BidirectionalMutableCollection where .Element == String> = ...<br class=""><br class="">let input = "West Meoley"<br class=""><br class="">// Not actually necessary, since the compiler knows "a.Element" is String.<br class="">// A fully constrained anonymous associated type is synonymous with the concrete<br class="">// type it's forced to take on, and the two are interchangeable.<br class="">// However, 'as' casting is still available if desired.<br class="">let anonymousInput = input as a.Element<br class=""><br class="">a[a.startIndex] = anonymousInput<br class=""><br class="">// as mentioned, this also works:<br class="">a[a.startIndex] = input<br class=""><br class="">// If the collection allows it, set the first element in the collection to a given string.<br class="">func setFirstElementIn(inout collection: Any<Collection> toString string: String) {<br class=""> if let element = string as? collection.Element {<br class=""> // At this point, 'element' is of type "collection.Element"<br class=""> collection[collection.startIndex] = element<br class=""> }<br class="">}<br class=""></blockquote><br class="">Neither of these look like they actually make *use* of the fact that<br class="">there's type erasure involved (and therefore should probably be written<br class="">as generics?). The interesting cases with Any<Collection...>, for the<br class="">purposes of this discussion, arise when you have multiple instances of<br class="">the same existential type that wrap different concrete types.<br class=""></blockquote><br class="">One use case I have found is to work around the lack of higher-kinder<br class="">types. <br class=""></blockquote><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Really, now: a use-case for feature A that is a workaround for the lack</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">of feature B hardly justifies adding feature A! We do want to add</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">higher-kinded types eventually.</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""></div></blockquote><div> </div><div>Good to know. I thought higher-kinder types were on the “maybe if someone shows a compelling enough use case” list. AFAIK this is the first time a member of the core team has stated the intent to add them. If that is the case I agree that this use case isn’t relevant. The workaround isn’t great because it loses type information that is critical to the optimizer (but it’s all we have available today).</div><br class=""><blockquote type="cite" class=""><div class=""><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">If you have a protocol where specific implementations will return<br class="">different types, but all conform to a second protocol you can define<br class="">the protocol in terms of a generic type-erased wrapper which conforms<br class="">to the second protocol and accepts type arguments that match the<br class="">associated types (thus binding the associated types to concrete<br class="">types). I have found this to be a useful technique (granted it is a<br class="">workaround and I’m not sure how useful it would continue to be if<br class="">Swift eventually gets higher-kinder types).<br class=""><br class=""><blockquote type="cite" class=""><br class="">Another problem I see: in this new world, what is the model for choosing<br class="">whether to write a function as a protocol extension/generic, or as a<br class="">regular function taking existential parameters? Given that either of<br class="">the above could have been written either way, we need to be able to<br class="">answer that question. When existentials don't conform to their<br class="">protocols, it seems to me that the most general thing to do is use<br class="">existentials whenever you can, and only resort to using generics when<br class="">forced by the type system. This does not seem like a particularly good<br class="">programming model to me, but I might be convinced otherwise.<br class=""></blockquote><br class="">That doesn’t seem like a particularly good programming model to me either.<span class="Apple-converted-space"> </span><br class=""><br class="">The rule of thumb I am operating with for protocols with Self or<br class="">associated type requirements is to prefer generics and use type<br class="">erasure / existentials when that isn’t possible. For example, when<br class="">heterogeneity is required or when you can’t form the necessary type in<br class="">a protocol requirement (as in the preceding example).<br class=""><br class="">This heuristic has been working out pretty well for me thus far. <br class=""></blockquote><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">I do worry a bit that people will choose the opposite heuristic.</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">It would be somewhat reassuring to me if we could prove to ourselves</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">that, using your heuristic, one is never forced to copy/paste a generic</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">function implementation into a corresponding function that uses</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">existentials.</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">The primary impact of introducing a language mechanism for generalized<br class="">existentials in my code would be to eliminate a lot of manual type<br class="">erasing boilerplate.<br class=""></blockquote><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">If your code has many manual type erasing wrappers corresponding to</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">protocols with associated types and/or Self requirements that also never</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">have to trap type mismatches, that would certainly be instructive</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">empirical data. Would you care to share the protocols and wrappers you</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">are talking about?</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""></div></blockquote><div><br class=""></div><div>I put together a sample implementation of a Cocoa-like responder chain in Swift a while ago when the “Swift dynamism” debate was raging. </div><div><br class=""></div><div>It isn't intended to be a Swifty design. It is intended to be similar to Cocoa and show techniques that can be used to do things similar to Cocoa’s responder chain and targer-action in Swift. It uses a type erased wrapper for actions that binds `Sender` while hiding the concrete `Action` type and also the `Handler` associated type. It cannot and should not conform to the protocol it is derived from and could be replaced with the generalized existentials in Austin’s proposal.</div><div><br class=""></div><div><a href="https://gist.github.com/anandabits/ec26f67f682093cf18b170c21bcf433e" class="">https://gist.github.com/anandabits/ec26f67f682093cf18b170c21bcf433e</a></div><div><br class=""></div><div>This is a good example to start with because it is related to a topic that has been hotly debated and is clearly something a lot of people want to be able to do.</div><br class=""><blockquote type="cite" class=""><div class=""><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class="">Anyway, my overall point is that this all seems like something we *can*<br class="">do and that nicely fills gaps in the type system, but not necessarily<br class="">something we *should* do until we better understand what it's actually<br class="">*for* and how it affects the programming model.<br class=""></blockquote><br class="">That’s a very fair position to take. :)<br class=""><br class=""><blockquote type="cite" class=""><br class="">--<span class="Apple-converted-space"> </span><br class="">Dave<br class=""></blockquote><br class=""></blockquote><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">--<span class="Apple-converted-space"> </span></span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Dave</span></div></blockquote></div><br class=""></body></html>