> On Apr 6, 2016, at 11:30 AM, Developer via swift-evolution
> <[email protected]> wrote:
>
> If you've ever gotten to the point where you have a sufficiently generic
> interface to a thing and you need to constrain it, possibly in an extension,
> maybe for a generic free function or operator, you know what a pain the
> syntax can be for these kinds of operations. For example, the Swift book
> implements this example to motivate where clauses
>
> func anyCommonElements <T: SequenceType, U: SequenceType where
> T.Generator.Element: Equatable, T.Generator.Element == U.Generator.Element>
> (lhs: T, _ rhs: U) -> Bool
>
> This is noisy and uncomfortable to my eyes, and almost impossible to align
> correctly. Per a short discussion on Twitter with Joe Groff and Erica Sadun,
> I'd like so see what the community feels about moving the where clause out of
> the angle brackets. So that example becomes
>
> func anyCommonElements <T: SequenceType, U: SequenceType>
> where T.Generator.Element: Equatable, T.Generator.Element ==
> U.Generator.Element
> (lhs: T, _ rhs: U) -> Bool
>
> Or, if you're feeling ambitious, even
>
> func anyCommonElements <T, U>
> where T : SequenceType, U : SequenceType,
> T.Generator.Element: Equatable, T.Generator.Element == U.Generator.Element
> (lhs: T, _ rhs: U) -> Bool
>
> Thoughts?
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. */
{
}
As others noted, it's also appealing to do this for type declarations too:
struct Foo<T: Foo, U: Bar>
where T.Foo == U.Bar
{
}
and that gives a consistent feeling with extensions and protocol declarations.
-Joe
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
