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

[Ross O'Brien]

It's probably appropriate. Given that, in this example, Bar implicitly
unifies its generic constraint T with Foo's associatedtype T (or,
typealiases T with T), you need to be at least a little careful how you
name your generic constraints.

protocol Foo
{
    associatedtype T
}

struct<T> Bar : Foo
{
}

On Thu, Apr 7, 2016 at 12:52 AM, Erica Sadun via swift-evolution <
swift-evolution at swift.org> wrote:

>
> On Apr 6, 2016, at 5:45 PM, David Waite via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
> On Apr 6, 2016, at 1:36 PM, Joe Groff via swift-evolution <
> swift-evolution at swift.org> 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
> 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/7aeaa1c0/attachment.html>