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

[Dany St-Amant]

> Le 6 avr. 2016 à 16:03, Joe Groff via swift-evolution <swift-evolution at swift.org> a écrit :
> 
> 
>> On Apr 6, 2016, at 12:52 PM, Pyry Jahkola <pyry.jahkola at iki.fi> wrote:
>> 
>> Joe,
>> 
>> Just from your experience on this topic, is there any reason not to also move the primary constraints into the trailing `where` clause?
>> 
>> So instead of what you wrote, we'd have it this way:
>> 
>>    func foo<T, U>(x: T, y: U) -> Result<T,U>
>>       where T: Foo, U: Bar, T.Foo == U.Bar /*, etc. */
>>    {
>>    }
>> 
>> …as well as:
>> 
>>    struct Foo<T, U>
>>       where T: Foo, U: Bar, T.Foo == U.Bar
>>    {
>>    }
>> 
>> Like I said earlier in this thread, I think this would also make the `extension` syntax more uniform with types (by turning generic parameters into strictly locally visible things):
>> 
>>    extension Foo<T, U> where U == Baz { // (Could've used X and Y here as well.)
>>        // Now it's clear where the names T and U come from.
>>        var bazzes: [U] { return ... }
>>    }
> 
> It's a judgment call. It's my feeling that in many cases, a generic parameter is constrained by at least one important protocol or base class that's worth calling out up front, so it's reasonable to allow things like 'func foo<C: Collection>(x: C) -> C.Element' without banishing the 'Collection' constraint too far from the front of the declaration.
> 

I'm with Joe here on not banning it. Having the key constraint up front seems make it easier to grasp the goal of the generic function with a quick glance.

Flexibility around the constraint already exist, as one can currently write:

func foo<C where C: Collection>(x: C) -> C.Element

But probably few do so (maybe just because it's longer to type)

Dany