[swift-evolution] [Review] SE-0081: Move where clause to end of declaration

[David Hart]

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
{

Do you need believe this is now more readable?

David.

> On 15 May 2016, at 02:26, Karl Wagner via swift-evolution <swift-evolution at swift.org> 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 <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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160515/ba9495fb/attachment.html>