Because I am a mailing list noob, my email wasn't CC'd to all. So here we go
again:
Big +1 from me.
I expected not to like this syntax but I believe it makes it far clearer. It
always felt backwards to me to have to come up with all the constraints before
the function signature. Maybe this is moot because you should already know what
the function should look like before writing. But we are all human and things
may change as we are writing it, resulting in a constant going back and forth
from the signature to the constraints.
It reads much more naturally (and I think it's easier to write) when the where
clause is after the signature because you have to look *back* to the parameters
in the function instead of looking forward. And when having to look forward,
you have to parse a possibly long list of constraints before even finding the
signature. Repeat this possibly for each constraint and there is some mental
overload there.
With the where at the end, you've already read the function signature and the
signature is in a known easy to find place when looking back at it.
So in summary:
- it reads more naturally
- more comfortable on the eyes
- easier to find the function signature when looking back after reading the
constraints
This all leads to less mental overload IMO
Brandon
> On Apr 6, 2016, at 2:37 PM, Shawn Erickson via swift-evolution
> <swift-evolution@swift.org> wrote:
>
>
>
> On Wed, Apr 6, 2016 at 11:36 AM Pyry Jahkola via swift-evolution
> <swift-evolution@swift.org> wrote:
>>> On 06 Apr 2016, at 21:30, Developer via swift-evolution
>>> <swift-evolution@swift.org> wrote:
>>
>>>
>>> If you've ever gotten to the point where you have a sufficiently generic
>>> interface to a thing and you need to constrain it, possibly in an
>>> extension, maybe for a generic free function or operator, you know what a
>>> pain the syntax can be for these kinds of operations.
>>
>> +1 already!
>>
>>> Or, if you're feeling ambitious, even
>>>
>>> func anyCommonElements <T, U>
>>> where T : SequenceType, U : SequenceType,
>>> T.Generator.Element: Equatable, T.Generator.Element == U.Generator.Element
>>> (lhs: T, _ rhs: U) -> Bool
>>
>>
>> I would actually move them as far as after everything else, and right before
>> the definition body. For the above function that would mean:
>>
>> func anyCommonElements<T, U>(lhs: T, _ rhs: U) -> Bool
>> where T : SequenceType,
>> U : SequenceType,
>> T.Generator.Element: Equatable,
>> T.Generator.Element == U.Generator.Element
>> {
>> ...
>> }
>>
>> That would make the definition look closer to what the call site looks like.
>>
>> The same would work for generic types too:
>>
>> public struct Dictionary<Key, Value>
>> where Key : Hashable
>> {
>> ...
>> }
>
> I very much like this suggestion.
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
