> On Apr 6, 2016, at 5:45 PM, David Waite via swift-evolution > <[email protected]> wrote: > > >> On Apr 6, 2016, at 1:36 PM, Joe Groff via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> I think this is a good idea, though I would put the `where` clause after the >> function signature: >> >> func foo<T: Foo, U: Bar>(x: T, y: U) -> Result<T,U> >> where T.Foo == U.Bar /*, etc. */ >> { >> } > > A bit of a meta-argument: > > It is very common to use single-capital letter generic parameters, and the > API style does not give guidance around the naming of generic parameters. > > However in my humble-but-opinionated view, they are effectively scope-bound, > dynamic type aliases. Declaring func "foo<T>" is like declaring “var i”, but > its forgiven since coming up with a good, concise name for such a type alias > can be hard. > > The standard library seems inconsistent about this as well: > > func == <A : Equatable, B : Equatable>(_: (A, B), rhs: (A, B)) > > vs. > > func == <Key : Equatable, Value : Equatable>(_: [Key : Value], rhs: [Key : > Value]) > > The argument I bring up is that naming of the generic parameters may wind up > affecting whether the code is clearer having type constraints and the where > clause within the brackets or trailing the function. It is important to take > this into account and compare both apples to apples and oranges to oranges > when evaluating syntax. > > (or, change the API guide and standard library to discourage either apples or > oranges) > > -DW
I'll keep this short. IMO: * Dictionaries have semantics, so Key/Value makes sense. * Truly "generic" equatable values do not, so A and B are simple stand-ins. * Always prefer named tokens when there are actual semantics (Element, Wrapped, etc). This may or may not be appropriate for inclusion in the API guidelines. -- E
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
