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

[Thorsten Seitz]

> Am 14.05.2016 um 20:19 schrieb Tony Allevato via swift-evolution <swift-evolution at swift.org>:
> 
> 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.

But this scatters the function definition itself, i.e. the name of the function and its parameter list and return type over multiple lines.
And splitting the <> over multiple lines is really ugly. The leading > even looks like an operator (is it func >(value: S) being defined?).

I think 

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

is much more readable.

Or what about using some more suggestive names for the generic paramters, so that the core of the function definition can be kept even shorter without loosing readability:

func someMethod<Seq, Elem>(value: Seq) -> AnySequence<Elem>
	where
	Seq: SequenceType,
	Seq.Generator.Element == Elem {
	…
}

Here, I don’t see the need to keep all constraints up front because the generic parameters already suggest their nature. The where clause just fills in the technical constraints.

This would not be possible with the current syntax at all.

-Thorsten


> 
> 
>> 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
> 
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution