<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 &lt;<a href="mailto:dabrahams@apple.com" class="">dabrahams@apple.com</a>&gt; 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 &lt;</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="">&gt; 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 &lt;<a href="mailto:dabrahams@apple.com" class="">dabrahams@apple.com</a>&gt; wrote:<br class=""><br class=""><br class="">on Wed Jun 08 2016, Matthew Johnson &lt;<a href="http://matthew-at-anandabits.com/" class="">matthew-AT-anandabits.com</a><span class="Apple-converted-space">&nbsp;</span>&lt;<a href="http://matthew-at-anandabits.com/" class="">http://matthew-at-anandabits.com/</a>&gt;&gt; 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 &lt;<a href="mailto:dabrahams@apple.com" class="">dabrahams@apple.com</a>&gt; wrote:<br class=""><br class=""><br class="">on Tue Jun 07 2016, Matthew Johnson &lt;<a href="http://matthew-at-anandabits.com/" class="">matthew-AT-anandabits.com</a>&gt; 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 &lt;<a href="mailto:dabrahams@apple.com" class="">dabrahams@apple.com</a>&gt; wrote:<br class=""><br class=""><br class="">on Tue Jun 07 2016, Matthew Johnson &lt;<a href="http://matthew-at-anandabits.com/" class="">matthew-AT-anandabits.com</a><span class="Apple-converted-space">&nbsp;</span>&lt;<a href="http://matthew-at-anandabits.com/" class="">http://matthew-at-anandabits.com/</a>&gt;&gt; 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 &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:<br class=""><br class=""><br class="">on Tue Jun 07 2016, Matthew Johnson &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; 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? &nbsp;How so? &nbsp;Generalized existentials should still be<br class="">type-safe. &nbsp;<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. &nbsp;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. &nbsp;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. &nbsp;I said “hypothetical” because producing a compile time error<br class="">rather than a runtime trap is the only sane thing to do. &nbsp;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? &nbsp;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. &nbsp;<br class=""></blockquote><br class="">This isn’t directly related to having self or associated type<br class="">requirements. &nbsp;It is true of all existentials. &nbsp;<br class=""></blockquote><br class="">That is just an implementation limitation today, IIUC. &nbsp;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. &nbsp;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. &nbsp;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. &nbsp;But you couldn't pass the<br class="">existential to a generic function like<br class=""><br class="">func scrambled&lt;C: Collection&gt;(_ c: C) -&gt; [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 &amp; 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? &nbsp;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. &nbsp;It’s too easy to write something like that<br class="">without realizing that it introduces the possibility of a crash. &nbsp;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. &nbsp;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. &nbsp;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. &nbsp;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). &nbsp;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="">/// &nbsp;&nbsp;must be a valid index of the collection that is not equal to the<br class="">/// &nbsp;&nbsp;`endIndex` property.<br class="">@trapping public subscript(position: Self.Index) -&gt; 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). &nbsp;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?`. &nbsp;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. &nbsp;<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. &nbsp;Sure, those methods aren’t<br class="">going corrupt memory, but they *are* going to explicitly and<br class="">intentionally crash for some inputs. &nbsp;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. &nbsp;It's safe in exactly the same way that<br class="">array indexes and integers are. &nbsp;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? &nbsp;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">&nbsp;</span>&lt;<a href="https://swift.org/about/" class="">https://swift.org/about/</a>&gt;:<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. &nbsp;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. &nbsp;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. &nbsp;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? &nbsp;<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. &nbsp;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. &nbsp;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. &nbsp;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. &nbsp;<br class=""></blockquote><br class="">Of course. &nbsp;As I've said, let's look at the use cases.<br class=""></blockquote><br class="">Agree. &nbsp;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. &nbsp;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. &nbsp;Sometimes you bind *all* of the associated types to<br class="">concrete types and the protocol has no `Self` requirements. &nbsp;In that<br class="">case there is no trouble at all in conforming the type-erased<br class="">“existential" to the protocol itself. &nbsp;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. &nbsp;<br class=""><br class="">We have known use-cases, currently emulated in the standard library, for<br class="">existentials with erased type relationships. &nbsp;*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. &nbsp;Note: I have<br class="">not seen anyone build an emulation of the other kind of generalized<br class="">existential. &nbsp;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 . &nbsp;These are all<br class="">syntactically explicit unsafe / dangerous operations. &nbsp;All other traps<br class="">are in the standard library (array index, overflow, etc). &nbsp;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. &nbsp;<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. &nbsp;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. &nbsp;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. &nbsp;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). &nbsp;<br class=""></blockquote><br class="">I don't accept either of those statements without seeing some analysis<br class="">of the use-cases. &nbsp;For example, I don't believe that AnyCollection et al<br class="">are particularly crash-prone. &nbsp;The likelihood that you'll use the wrong<br class="">index type with a collection is very, very low. &nbsp;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. &nbsp;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. &nbsp;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. &nbsp;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. &nbsp;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. &nbsp;People may be<br class="">designing around the need for them. &nbsp;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. &nbsp;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. &nbsp;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. &nbsp;I agree that use cases should be carefully considered. &nbsp;<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. &nbsp;I don’t understand why you think this<br class="">approach is insufficient. &nbsp;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">&nbsp;</span>&lt;<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>&gt; &lt;<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>&lt;<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>&gt;&gt;<br class=""><br class="">let a : Any&lt;Collection&gt;<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">&nbsp;</span><br class="">func swapFirstAndLast(inout collection: Any&lt;BidirectionalMutableCollection&gt;) {<br class="">&nbsp;&nbsp;// firstIndex and lastIndex both have type "collection.Index"<br class="">&nbsp;&nbsp;guard let firstIndex = collection.startIndex,<br class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;lastIndex = collection.endIndex?.predecessor(collection) where lastIndex != firstIndex else {<br class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;print("Nothing to do")<br class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return<br class="">&nbsp;&nbsp;}<br class=""><br class="">&nbsp;&nbsp;// oldFirstItem has type "collection.Element"<br class="">&nbsp;&nbsp;let oldFirstItem = collection[firstIndex]<br class=""><br class="">&nbsp;&nbsp;collection[firstIndex] = collection[lastIndex]<br class="">&nbsp;&nbsp;collection[lastIndex] = oldFirstItem<br class="">}<br class=""><br class="">var a : Any&lt;BidirectionalMutableCollection where .Element == String&gt; = ...<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&lt;Collection&gt; toString string: String) {<br class="">&nbsp;&nbsp;if let element = string as? collection.Element {<br class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// At this point, 'element' is of type "collection.Element"<br class="">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;collection[collection.startIndex] = element<br class="">&nbsp;&nbsp;}<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?). &nbsp;The interesting cases with Any&lt;Collection...&gt;, 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. &nbsp;<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! &nbsp;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>&nbsp;</div><div>Good to know. &nbsp;I thought higher-kinder types were on the “maybe if someone shows a compelling enough use case” list. &nbsp;AFAIK this is the first time a member of the core team has stated the intent to add them. &nbsp;If that is the case I agree that this use case isn’t relevant. &nbsp;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). &nbsp;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? &nbsp;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. &nbsp;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. &nbsp;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">&nbsp;</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. &nbsp;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. &nbsp;<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. &nbsp;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. &nbsp;</div><div><br class=""></div><div>It isn't intended to be a Swifty design. &nbsp;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. &nbsp;It uses a type erased wrapper for actions that binds `Sender` while hiding the concrete `Action` type and also the `Handler` associated type. &nbsp;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. &nbsp;:)<br class=""><br class=""><blockquote type="cite" class=""><br class="">--<span class="Apple-converted-space">&nbsp;</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">&nbsp;</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>