> Le 6 avr. 2016 à 16:03, Joe Groff via swift-evolution
> <swift-evolution@swift.org> a écrit :
>
>
>> On Apr 6, 2016, at 12:52 PM, Pyry Jahkola <pyry.jahk...@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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
