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.
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
