I would think it’d just be unconstrained generic parameters - same as this is
now:
func f<A, B>(lhs: A, _ rhs: B) {}
However I can see how it’d certainly be potentially too confusing. It might be
worthwhile to retain the brackets, but require type restrictions to be moved to
the trailing “where” so that it keeps the <> part as short as possible, so this
would be an error:
func f<A: SequenceType, B: Equatable>(lhs: A, _ rhs: B) -> Bool {}
And would have to be written:
func f<A, B>(lhs: A, _ rhs: B) -> Bool where A: SequenceType, B: Equatable {}
Maybe? That’s a bit longer, though. Maybe it’s not worth changing that aspect
of it. I like moving “where” to the end, though.
l8r
Sean
> On Apr 6, 2016, at 1:53 PM, Timothy Wood <[email protected]> wrote:
>
>
>> On Apr 6, 2016, at 11:48 AM, Sean Heber via swift-evolution
>> <[email protected]> wrote:
>>
>> This almost seems like it could work so that it didn't even need the
>> bracketed parts to be able to figure out the types:
>>
>> func anyCommonElements(lhs: T, _ rhs: U) -> Bool where
>> T : SequenceType,
>> U : SequenceType,
>> T.Generator.Element: Equatable,
>> T.Generator.Element == U.Generator.Element
>> {}
>>
>
> ... though if there are no type constraints, this would be ambiguous:
>
> // If there are no know types T and R in scope, is this an error or are
> T and R assumed to be unconstrained generic parameters?
> func f(arg: T) -> R
>
> -tim
>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
