[swift-evolution] [Pitch] Moving where Clauses Out Of Parameter Lists
Matthew Johnson
matthew at anandabits.com
Wed Apr 6 19:36:40 CDT 2016
Sent from my iPad
On Apr 6, 2016, at 7:13 PM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:
>> I would actually move them as far as after everything else, and right before the definition body. For the above function that would mean:
>>
>> func anyCommonElements<T, U>(lhs: T, _ rhs: U) -> Bool
>> where T : SequenceType,
>> U : SequenceType,
>> T.Generator.Element: Equatable,
>> T.Generator.Element == U.Generator.Element
>> {
>> ...
>> }
>>
>> That would make the definition look closer to what the call site looks like.
>>
>> The same would work for generic types too:
>>
>> public struct Dictionary<Key, Value>
>> where Key : Hashable
>> {
>> ...
>> }
>
> Another nice thing about this style is that, in principle, I think it could be extended to specify requirements on non-type parameter values.
>
> func ..< <Element: Incrementable>(lhs: Element, rhs: Element) -> Range<Element>
> where Element: Comparable, lhs <= rhs {
> …
> }
>
> I'm not saying we must or even should include that feature, merely that it gives us a nice syntactic slot to use if we choose to do so later.
I know you're not proposing that feature right now, but want to understand how you expect it to work. It looks to me like this starts to enter design by contract territory. Would the predicate behave as if it was part of a precondition?
> --
> Brent Royal-Gordon
> Architechies
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
More information about the swift-evolution
mailing list