> Am 25.05.2016 um 21:22 schrieb Brent Royal-Gordon via swift-evolution
> <swift-evolution@swift.org>:
>
>> But if we are going to remove the ability to use typealiases bound to `Any`
>> in constraints we need to introduce an alternative mechanism for factoring
>> out constraints (hopefully a superior mechanism that can abstract over
>> constraints that relate generic parameters to each other).
>
> I could certainly imagine having, for instance, a `constraintalias` keyword:
>
> constraintalias HashableAndComparable = Hashable, Comparable
> constraintalias CollectionOfConforming<ElementConstraint> = Collection
> where .Element: ElementConstraint
The second one is not really a constraintalias but a regular generic typealias
making use of an abstracted constraint, isn’t it?
If we use `P & Q` instead of `Any<P, Q>` and just `P` instead of `Any<P>` we
not only avoid the confusion between `Any<P>` being the same as `P` in case of
P not having associated types or self constraints, we also don’t have to
distinguish between using existentials as types and constraints, and we don’t
have to introduce something like constraintalias, because typealias is
sufficient.
i.e.
typealias HashableAndComparable = Hashable & Comparable
typealias CollectionOfConforming<ElementConstraint> = Collection where
.Element: ElementConstraint
let a: HashableAndComparable = 123
let b: Hashable & Comparable = 123
func sum<C: CollectionOfConforming<Integer>>(numbers: C) -> C.Iterator.Element {
return numbers.reduce(0, combine: +)
}
-Thorsten
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
