> On May 15, 2016, at 9:17 AM, David Hart <[email protected]> wrote: > > Hi Karl, > > As author of this proposal, the one about constraints on associated types, > and the one on type-aliases in protocols (all from the Generics Manifesto - > original authorship to Douglas Gregor) I’d like to provide additional > reasoning behind my wish to push this proposal through, as a whole. > > First of all, there is a personal preference. I’ve used C# for many many > years, which has its where clause at the end of the declaration (like this > proposal), and I’ve used Swift since its unveiling. The experience with using > both styles for several years makes me favour this proposal’s syntax because > I find it much easier to read and format for readability. > > Constraints on associated type will provide more expressivity but I doubt it > will greatly reduce protocol constraint clauses in a majority of cases. And > yes, type-aliases in protocols will shorten clauses, but I still think they > will more readable with the where clause at the end. > > For example, here is a method I took (as-is) from the Standard Library which > has a few constraints, and which I further simplified if we imagine that > Sequence has an Element typealias for Iterator.Element: > > > internal func _arrayOutOfPlaceReplace< > B : _ArrayBufferProtocol, C : Collection > where > C.Element == B.Element, > B.Index == Int > >( > _ source: inout B, _ bounds: Range<Int>, _ newValues: C, _ insertCount: Int > ) { > > See how the Standard Library authors formatted it for readability and how as > a consequence arguments which use the generic types are further apart from > the declaration of those generic types. But with this proposal, the > declaration might be formatted to: > > internal func _arrayOutOfPlaceReplace<B, C>(_ source: inout B, _ bounds: > Range<Int>, _ newValues: C, _ insertCount: Int) where > B : _ArrayBufferProtocol, > C : Collection, > C.Iterator.Element == B.Element, > B.Index == Int > {
Reading this example reinforces my initial sense that while WHERE works well when the information is inlined, I would have preferred WITH in the case where the information is at the end. go figure... > > Do you need believe this is now more readable? > > David. > >> On 15 May 2016, at 02:26, Karl Wagner via swift-evolution >> <[email protected]> wrote: >> >> There is a lot not to like about the idea; even if it was optional. >> Personally, I feel the problem is solved in a much, much more elegant manner >> by other proposals. >> >> Firstly, the stuff after the ‘where’ clause is getting shorter once >> typealiases come to protocols. C.Iterator.Element become C.Element. In this >> one example, that’s 18 characters down to 9 - a 50% reduction in length. We >> tend to use quite expressive names for associated types, so I expect we’ll >> see similar gains elsewhere from this very simple proposal. >> >> Not only that, but there’s a very good proposal to add ‘where’ clauses to >> associated types in the protocols themselves, which will likely further >> reduce the verbosity of the constraints you need to specify at each >> declaration site. >> https://github.com/hartbit/swift-evolution/blob/9acd75abfbe626bbb3f9458cc3f6edb1d1f88c95/proposals/XXXX-associated-types-constraints.md >> >> And then we have generic typealiases and generalised existentials, which >> would allow us to wrap those ‘where’ clauses in to something much more >> intelligible to a human being at first glance. ‘StringCollection’ or >> ‘CollectionOfStrings’ is much clearer than <C:Collection where >> C.Element==String>, no matter how you chop it up. >> >> If I look at the other proposals, and where we are headed with much more >> expressive typealiases and associated types, I just feel that that’s the >> future: that’s the “swift’ way. It’s like type inference - all of the strict >> constraints are still there under-the-hood, but you’re able to work at a >> much clearer and more obvious abstraction level. This proposal pulls us >> further away from things like ‘obviousness’, and like I said, simply feels >> like an inelegant solution. >> >> At the very least, I think we should shelve the discussion until the larger >> expansion of typealiases, etc is complete. We should re-evaluate at that >> time, with a bigger set of more general-purpose tools to produce readable >> code. >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
