on Wed Mar 16 2016, Joe Groff <[email protected]> wrote: >> On Mar 16, 2016, at 5:02 PM, Chris Lattner <[email protected]> wrote: >> >> On Mar 16, 2016, at 4:56 PM, Joe Groff <[email protected] >> <mailto:[email protected]>> wrote: >>>> We shouldn’t infer it the requirement. >>>> > >>>> Rationale: I see this as analogous (in two ways) to why we don’t infer >>>> hashability of T in: >>>> >>>> func f<T>(…) { >>>> let x : Dictionary<T, String> >>>> } >>> >>> However, we do infer the `T: Hashable` in a case like this: >>> >>> func foo<T>(x: Dictionary<T, String>) {} >>> >>> `typealias` feels similar to that to me. It doesn't have to be a global >>> analysis, just an analysis of the RHS of the typealias. >> >> I consider the RHS of the typealias to be the “body” of the type alias, and >> parameters to be part of the “signature” of the funcdecl. > > I'm OK starting with the base design that constraints have to be > explicit. My gut tells me though that `typealias` is close enough > syntactically to `var` that many people will expect the inference to > occur, but we can always add it later.
I have the same concern as Joe does, but am willing to wait until people complain :-) -- Dave _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
