> Am 14.05.2016 um 20:19 schrieb Tony Allevato via swift-evolution
> <[email protected]>:
>
> 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
>> <[email protected]> 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
>> [email protected]
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
