added a few comments to https://gist.github.com/lmihalkovic/68c321ea7ffe27e553e37b794309b051 to clarify the rational. it is by no mean the only way or a good way, but IMO there are far worse ways to do the same.
> On Jun 6, 2016, at 1:20 AM, Douglas Gregor via swift-evolution > <[email protected]> wrote: > > >> On May 18, 2016, at 12:35 AM, Austin Zheng <[email protected] >> <mailto:[email protected]>> wrote: >> >> I've put together a considerably more detailed draft proposal, taking into >> account as much of Matthew's feedback as I could. You can find it below: >> >> https://github.com/austinzheng/swift-evolution/blob/az-existentials/proposals/XXXX-enhanced-existentials.md >> >> <https://github.com/austinzheng/swift-evolution/blob/az-existentials/proposals/XXXX-enhanced-existentials.md> >> >> Since there is no chance this will come up for review anytime soon, I expect >> to make significant revisions to it over the next month or so. Any feedback >> would be greatly appreciated. > > This is very much Swift 4 territory, but I can’t help myself… so… > > The actual feature description is spread out through this very long document, > with user-facing ideas (e.g., using “anonymous associated types”) intermixed > with deeper technical details (existential type equivalence), so it’s very > daunting to read. Please bring the user-facing features to the front > (“Proposed Solution”) with examples, and save the deeper technical details > for “Detailed Design”. You want more readers to make it through the part that > affects them. > > Shortcut 'dot' notation: If there is only one protocol with associated types > specified in the requirements, and there are no nested Any<...> requirements > with where clauses of their own, that protocol's name can be omitted from the > whereclause constraints: > > // Okay > // Would otherwise be Any< ~ where Collection.Element == Int> > let a : Any<class, Collection, Any<Streamable, CustomStringConvertible> where > .Element == Int> > > // NOT ALLOWED > // Both Collection and OptionSetType have associated types. > let b : Any<Collection, OptionSetType where .Element == Int> > FWIW, I think “.Element == Int” should be the only syntax. In generic > signatures, if you have two different protocols with same-named associated > types, and a given type parameter (or associated type) conforms to both > protocols, the associated types are (implicitly) made equivalent via an > inferred same-type constraint. So there’s no reason to introduce the > “Collection.Element == Int” syntax, because the “Collection” part is > basically irrelevant. > > Once existentials have been suitably enhanced, there is a strong analogy > between an existential and a generic signature with a single type parameter > that you can’t name. An existential Any<Collection where .Element : > Equatable> has most of the same characteristics as a generic something with > the signature <T : Collection where T.Element : Equatable>. Specifically, the > sections on “Existential type equivalence”, “Ordering”, “Real types to > anonymous associated types”, “Anonymous associated types to real types”. > could be reduced to a few small, simple examples and a mention of the > analogous behavior of generics. It will be far easier to explain this way, > and readers don’t need to get immersed in the details. Where there are > differences vs. generics, that’s important to point out. > > “Associated typealias rewriting”: this also falls out of the equivalence with > generics + SE-0092. > > “Associated types and member exposure”: you don’t make the point that it only > makes sense to refer to the associated types of a let constant; a var could > change its type dynamically, which would invalidate the typing rules. Did you > consider just using “x.dynamicType” in the type grammar for this? It’s more > general, in that you can refer to associated types but also talk about the > dynamic type of “x” itself, e.g., > > let x: Equatable = … > let y: Equatable = … > if let yAsX = y as? x.dynamicType { … x == yAsX … } > > which is (almost?) as powerful as a general “open” expression. > > I’m not a fan of the “anonymous associated types” terminology: these are > associated types of a type of some runtime-defined value. The only thing > “anonymous” about them is that it’s harder to spell the base type; otherwise, > they’re just like associated types of a generic type parameter. Again, the > generics analogy is strong here. > > FWIW, I don’t think we’ll ever need “opening existentials” with what you’ve > described here. Also, remember that a method of a protocol extension > essentially opens “Self”, so we already have one way to open an existential > (and that’s probably enough). > > I was a little surprised you didn’t point out that AnyObject could become > > typealias AnyObject = Any<class> > > or give the nice “AnyCollection” syntax: > > typealias AnyCollection<T> = Any<Collection where .Element == T> > > the latter of which is fairly important, because it gives nice syntactic sure > to one of the most highly-requested features [*]. I’d suggest having that > example very, very early. > > - Doug > > [*] That generally comes in as “Swift should have parameterized protocols…” > @doug : watched and very much appreciated your presentation on what makes a good API… reminded me of a job interview with Bertand Serlet a few years ago.. you guys have managed to remain very consistent over a very long period of time, and it looks like Swift is following in the foot-steps.
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
