<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 Dec 17, 2015, at 7:57 PM, Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" 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;">I’ve been going through some notes and realized I missed a couple of things when I put my list together:</div><div class="" 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;"><br class=""></div><div class="" 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;">* access control for extensions declaring protocol conformances </div><div class="" 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;">* memberwise deriving of protocol implementations</div><div class="" 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;"><br class=""></div><div class="" 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;">I also found an example of the “same type constraints” item I mentioned and it is different than discussed so far:</div><div class="" 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;"><div class=""><br class=""></div><div class="">struct S<T, U> {}</div><div class="">extension S where T == U {} // error</div></div><div class="" 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;"><br class=""></div><div class="" 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;">Are you considering any of these for Swift 3? </div></div></blockquote><div><br class=""></div><div>I’ve been picking Doug’s brain about this kind of stuff lately.</div><div><br class=""></div><div>This one is somewhat similar to a same type requirement making a generic type parameter concrete, in the sense that the number of ‘primary archetypes’ becomes smaller than the number of generic parameters, which isn’t handled everywhere yet. For example, SIL walks the list of primary archetypes in order to map a generic type parameter’s depth/index to an archetype in several places.</div><div><br class=""></div><div>With ‘secondary archetypes’, things are more flexible so this works:</div><div><br class=""></div><div>protocol P { typealias X }</div><div>func foo<T : P, U : P where T.X == U.X>()</div><div><br class=""></div><div>However, as Doug explained to me in person today, we’re still not doing a great job here. The list of requirements in a generic signature line up with the lists of primary and secondary archetypes in a tricky way. Also, type sugar allowing us to distinguish T.X from U.X is lost here since both types are mapped to the same identical type while building the generic signature, which you can imagine leads to poor diagnostics in more complex examples. Instead they need to have the same canonical type but still print differently, much like (X) and X, or [X] and Array<X>.</div><div><br class=""></div>Slava</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="" 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;"><br class=""></div><div class="" 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;">Access control for extensions declaring protocol conformances seems is the highest priority out of this group IMO.</div><div class="" 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;"><br class=""></div><div class="" 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;">Matthew</div><div class="" 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;"><br class=""></div><br class="" 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;"><div 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=""><div class="">On Dec 15, 2015, at 10:45 PM, Douglas Gregor <<a href="mailto:dgregor@apple.com" class="">dgregor@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="auto" class=""><div class="">Hi Matthew,<br class=""><br class="">Sent from my iPhone</div><div class=""><br class="">On Dec 15, 2015, at 7:25 PM, Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div class=""><div class="">Dmitri, Slava and Doug thank you for taking the time to respond. I apologize for not thanking you sooner. </div><div class=""><br class=""></div><div class="">Since the core team has a loosely shared understanding of the goals but hasn't had time to write it down yet I thought it might be helpful if I put together a summary of the features that seem to me like obvious candidates for completing the current generic system. If I have missed anything significant please point that out. </div></div></div></blockquote><div class=""><br class=""></div><div class="">This is helpful, thank you!</div><div class=""><br class=""></div><div class="">Lots of comments below. An overarching theme here is that I'm trying to scope down the list to what we need to achieve ABI stability and an expressive library fewer features means we're more likely to succeed with better quality. </div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><div class="">I'm placing a "**" next to items that I beleive I have seen mentioned by the core team as desired features. This is based on memory and may be innacurate or may be based on desires expressed, but not necessarily pinned to the Swift 3 timeline. </div><div class=""><br class=""></div><div class="">I'm hoping the core team might be able to indicate which items are likely to be part of the work you're doing on Swift 3, which items you might be interested in the community contributing to, and which items are unliekly to be considered during the Swift 3 timeframe even with community involvement. This could help interested contributors start thinking about what they might be interested in working on while we wait for a more complete document describing the vision.</div><div class=""><br class=""></div><div class="">- ** generic typealias</div></div></div></blockquote><div class=""><br class=""></div>This isn't high on my list. It's a good feature, and I want it someday, but introducing generic typealiases won't have any impact on the ABI and therefore can wait IMO. <div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class=""><div class=""><br class=""></div><div class="">- allow protocols to specify a non-covarying Self in static method declarations (a possible solution to the problem of conforming non-final classes in Cocoa to protocols containing factory methods)</div></div></div></blockquote><div class=""><br class=""></div>Maybe. This isn't terribly high on my list, but in also behind on the discussion. <br class=""><blockquote type="cite" class=""><div class=""><div class=""><div class=""><br class=""></div><div class="">- extensions</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>- ** allow same type constraints</div></div></div></blockquote><div class=""><br class=""></div>I'm assuming you mean an extension like </div><div class=""><br class=""></div><div class=""> extension Array where Element == String {}</div><div class=""><br class=""></div><div class="">Yes, it's something we want to support </div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class=""><div class=""><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>- ** allow protocol conformance in constrained extensions</div></div></div></blockquote><div class=""><br class=""></div>This is something like:</div><div class=""><br class=""></div><div class=""> extension Array : Equatable where Element : Equatable {}</div><div class=""><br class=""></div><div class="">It is very very high priority for Swift 3.</div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class=""><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>- allow protocol conformance in protocol extensions</div></div></div></blockquote><div class=""><br class=""></div>This is something like:</div><div class=""><br class=""></div><div class=""> extension CollectionType : Equatable where Generator.Element : Equatable {}</div><div class=""><br class=""></div><div class="">This is probably not a priority for Swift 3. It seems very cool, and I've advocated for similar features in the past (in more static generics systems), but the potential for ambiguities with such definitions is very high and the runtime cost for asking questions such as "is this T Equatable?" can be very high when this feature is in play. </div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class=""><div class=""><br class=""></div><div class="">- associated type constraints</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>- use of Self as a superclass constraint</div></div></div></blockquote><div class=""><br class=""></div><div class="">This wasn't on my list at all. Care to elaborate on why this is important?</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>- ** where clause constraining inidividual associated types</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>- ** where clause relating multiple assocated types</div></div></div></blockquote><div class=""><br class=""></div><div class="">Yes to both. We need the to properly express some relationships in the standard library types, such as a SubSequence's Element type matching the Element type of the sequence itself. </div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><div class=""><br class=""></div><div class="">- existentials for protocols with associated types</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>- protocol existentials don't conform to the protocol itself</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>- ** fully bound: protocol<GeneratorType where Element == Int> </div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>- ** fully constrained: protocol<GeneratorType where Element: CustomStringConvertible></div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>- partially bound / constrained - allow access to members only mentioning constrained associated types</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>- ** unbound - allow access to members not mentioning Self or associated types</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>- composition: protocol<P1, P2 where P1.Associated: P3, P2.Associated == Int, P1.Other == P2.Other></div></div></div></blockquote><div class=""><br class=""></div>This one is tough. It is a very, very common user request and existentials are painfully under implemented in Swift. On the other hand, it's an additive feature that isn't likely (IMO!) to be important for ABI stabilization in the language or library. So, I would put it out of scope for Swift 3. </div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class=""><div class="">- nesting (per Slava's email)</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>- ** Generic types nested inside generic functions</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>- ** Generic types nested inside generic types</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>- ** Generic functions nested inside generic functions which capture values or outer generic types</div></div></div></blockquote><div class=""><br class=""></div><div class="">I think Slava and I disagree on this one ;)</div><div class=""><br class=""></div><div class="">I don't consider this critical for Swift 3. The compiler will greatly improve simply by making this work (because the dumb assumptions that block this feature likely trigger additional bugs), but we don't need to allow it for ABI stability. There are a handful of places in the standard library where we've had to promote a type that would normally be nested to the top level to work around this, but we could live with that as a smallish ABI wart in the long term and introduce generic typealiases to clean up the syntax once those features become available. </div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><div class="">Some things that I expect are out of scope for Swift 3 but am mentioning for completeness / confirmation of that:</div><div class=""><br class=""></div><div class="">- variadic generics</div><div class="">- higher kinded types</div><div class="">- higher rank types</div></div></div></blockquote><div class=""><br class=""></div>Agreed that all are out of scope for Swift 3. The first is a feature of particular interest to me... But absolutely is out of scope. I also want to eventually use variadic generics to extend arbitrary length tuples of Equatable types to make them Equatable, for example ;)</div><div class=""><br class=""></div><div class="">A couple features you didn't mention that I consider in scope for Swift 3 generics:</div><div class=""><br class=""></div><div class="">- generic subscripts (the standard library might need these), e.g.,</div><div class=""><br class=""></div><div class=""> subscript<C : SequenceType where C.Generator.Element == Index> (indices: C) -> [Index]</div><div class=""><br class=""></div><div class="">- recursive protocol constraints, where an associated type can be stated to conform to its enclosing protocol (directly or indirectly), eg,</div><div class=""><br class=""></div><div class=""> protocol SequenceType {</div><div class=""> typealias SubSequence : SequenceType</div><div class=""> }</div><div class=""><br class=""></div><div class="">- operators defined in types (only indirectly related to generics):</div><div class=""><br class=""></div><div class=""> extension Array where Element : Equatable {</div><div class=""> func ==(lhs: Array, rhs: Array) -> Bool { ... }</div><div class=""> }</div><div class=""><br class=""></div><div class="">- "real" default implementations in protocols. It looks like a syntactic simplification from</div><div class="">Putting the definition in an extension, but putting the default implementation in the protocol itself has an important effect on resilience: one should be able to add requirements to a protocol without breaking ABI so long as those requirements have a default implementation. </div><div class=""><br class=""></div><div class="">Several of these (recursive constraints, where clauses placing requirements on associated types in protocols, etc) are partly aimed at eliminated many of the underscored protocols in the standard library, because we don't want them to be part of the library ABI. </div><div class=""><br class=""></div><div class="">I suspect I'll remember other small things, but that's the "big" list... and it's size perhaps illustrates why we need to choose carefully to maintain focus. </div><div class=""><br class=""></div><div class=""> - Doug</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class=""><div class=""><div class="">Thanks,</div><div class="">Matthew</div></div><div class=""><br class=""></div><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 11, 2015, at 11:24 PM, Douglas Gregor <<a href="mailto:dgregor@apple.com" class="">dgregor@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 10, 2015, at 3:45 PM, Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">One of the stated focus areas for Swift 3 is to complete the generics system. <div class=""><br class=""></div><div class="">How far along is the design for the “complete” generics system? </div></div></div></blockquote><div class=""><br class=""></div><div class="">There’s a loose shared understanding of the pieces we need among the compiler and standard library developers that have been co-evolving the generics system, but it’s not written down in any single place.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">Is there appetite among the core team to involve the community in evaluating planned features or submitting proposals to complement existing plans?</div></div></div></blockquote><div class=""><br class=""></div><div class="">Yes, absolutely. I feel like we (the core team) need to articulate our vision here—what we feel we need to accomplish (in features, in the standard library API, in the implementation) in Swift 3 vs. what we believe we can introduce later on, how the pieces all fit together, etc.—to help facilitate those discussions.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">Also, is there any documentation other than<span class="Apple-converted-space"> </span><a href="https://github.com/apple/swift/blob/master/docs/Generics.rst" class="">https://github.com/apple/swift/blob/master/docs/Generics.rst</a><span class="Apple-converted-space"> </span>describing in detail what the complete vision for the generics system is and what new features will be added in Swift 3 (as well as any generics features that have been decided against for Swift or version 3 specifically)?</div></div></div></blockquote><br class=""></div><div class="">No, that document is the best overall documentation for the vision of the generics system, despite being mostly untouched for more than two years and lacking newer features (protocol extensions, anyone?).</div><div class=""><br class=""></div><div class="">So, we need to write up a document describing our vision here. It’s going to take a little time, both because it’s a nontrivial task and because the likely principal authors are also engaged in other large Swift 3 tasks (e.g., <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0005-objective-c-name-translation.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0005-objective-c-name-translation.md</a>)</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>- Doug</div><div class=""><br class=""></div><br class=""></div></div></blockquote></div><br class=""></div></blockquote></div></div></div></blockquote></div><br class="" 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;"><img src="https://u2002410.ct.sendgrid.net/wf/open?upn=NLTid1W7V2mxBEfr5Y3KfTntaxSmOQp5vjACZc9Eh1-2FcgGaqTJlv6fAZBjP3RGGz73leeG1RzPJUk-2B-2Bbv0MpgBRHWPgLPzaCKkcabSO3JAjFgVGu-2FlyNKJfMdLjpK-2BGwZqRDChQ13e3BiezJCjMtbRefEnElWC0wr1N1Hdk1a3nFEsLQzGmpv3k0QTgud1B25eliS8M2mJz5Aif0-2Ba-2BE8ldC28pdF61SMPtsnJK2ymE-3D" alt="" width="1" height="1" border="0" 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; height: 1px !important; width: 1px !important; border-width: 0px !important; margin: 0px !important; padding: 0px !important;" 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><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><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="">swift-evolution mailing list</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=""><a href="mailto:swift-evolution@swift.org" 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="">swift-evolution@swift.org</a><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=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" 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="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div></blockquote></div><br class=""></body></html>