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

[Tony Allevato]

On 2016-05-14 16:29:40 +0000, Haravikk via swift-evolution said:

> 
> On 14 May 2016, at 16:52, Tony Allevato via swift-evolution 
> <swift-evolution at swift.org> wrote:
> 
>> To me, this makes declarations with complex sets of constraints much 
>> harder to read, because I have to hunt them down instead of finding 
>> them all in one place. Under this proposal, the longer an argument list 
>> gets, the further separated the constraints are from the type 
>> parameters that use them.
> 
> This is partly an issue of how you use the feature rather than an issue 
> with the feature itself, as you’re assuming that everything is all on 
> one line, but really I think the intent of this feature is to better 
> support multi-line declarations. It enables things like:
> 
> 	func someMethod<S:SequenceType, T>(value:S) -> AnySequence<T>
> 		where S.Generator.Element == T { … }

I'm not assuming that. Under the current syntax, I would format your 
example as:

    func someMethod<
        S: SequenceType, T
        where S.Generator.Element == T
    >(value: S) -> AnySequence<T> {
        ...
    }

which I find to be quite readable across multiple lines without 
scattering the generic type information in two places across the 
function.


> The actual function signature stays on the top, but the constraint can 
> now move down neatly, since it’s a supplementary condition that you may 
> not to consider right away, or at all, if it’s just reinforcing some 
> kind of common-sense limitation.

That's kind of a judgment call, though. Not all constraints fit that 
mold—some encode very important information that it makes sense to keep 
up front.


> This is partly why I’d prefer to see it optional though, as some things 
> will fit on one line reasonably well (you probably could with the above 
> for example), but like you say, with it all on one line the return type 
> becomes less visible.

No matter how you format the proposed syntax, the return type is 
sandwiched in the middle of two things that describe generic type 
information—whether it's on one line or not doesn't change that. I 
believe that harms readability, especially if you have some constraints 
(conformance) on the left and some (associated types) on the right.

I would be strongly opposed to making this optional—that adds 
complexity to the language to support parsing two patterns, as well as 
the cognitive load of someone reading Swift code, especially if written 
in the different style. As was mentioned in another thread, "Swift is 
an opinionated languge", and I hope we'd be prescriptive about 
syntactic constructs like this that are more significant than "does the 
curly brace go on the same line or the next line". (Even if the choice 
is one that I disagree with in the end, I'd rather there be one way 
than multiple ways!)


> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution