> On Apr 6, 2016, at 12:52 PM, Pyry Jahkola <[email protected]> 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. -Joe _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
