I like the idea, I find the beginning of a declaration too cluttered and it obscures the main purpose. Like Brent I am wary of the design by contract (DBC) bit, `lhs <= rhs`. DBC is probably for a separate discussion, but moving the where clause would probably help.
-- Howard. On 7 April 2016 at 10:36, Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote: > > > Sent from my iPad > > On Apr 6, 2016, at 7:13 PM, Brent Royal-Gordon via swift-evolution < > swift-evolution@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@swift.org > > https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution