+1. Non-type generic parameters can be handled if/when they are proposed after Swift 3. There have to be better ways to encourage proper organization of the elements of a method header than forcing a redundant and non-obvious conformance to 'Any'; if this is mandatory the proposal is fatally flawed and should be taken back to the drawing board.
Austin > On May 16, 2016, at 2:36 AM, Thorsten Seitz via swift-evolution > <[email protected]> wrote: > > Having to declare conformance to `Any` is just noise and should *not* be > mandatory IMHO. > > -Thorsten > > >> Am 16.05.2016 um 07:59 schrieb Pyry Jahkola via swift-evolution >> <[email protected] <mailto:[email protected]>>: >> >> >>> On 16 May 2016, at 01:45, Brent Royal-Gordon via swift-evolution >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>> I'm actually tempted to suggest that a conformance should be *mandatory* >>> and you should have to specify `Any` if you don't have anything more >>> specific to say about the generic parameter: >>> >>> func map<T: Any>(@noescape transform: (Element) throws -> T) rethrows >>> -> [T] >> >> That's a good idea indeed if we ever intend to have other kinds of generic >> arguments (in particular, constant values like `length: Int`). >> >> Even so, I wouldn't want to prohibit adding more protocol constraints in the >> where clause even if you can introduce all constaints of `T` at once as `T: >> protocol<A, B>`. >> >> — Pyry >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
