[swift-evolution] [Pitch] Moving where Clauses Out Of Parameter Lists

Brandon Knope bknope at me.com
Thu Apr 7 10:40:47 CDT 2016


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 at swift.org> wrote:
> 
> 
> 
> On Wed, Apr 6, 2016 at 11:36 AM Pyry Jahkola via swift-evolution <swift-evolution at swift.org> wrote:
>>> On 06 Apr 2016, at 21:30, Developer via swift-evolution <swift-evolution at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160407/0b45b24d/attachment.html>


More information about the swift-evolution mailing list