Big +1 on this proposal from me. Does this proposal allow a protocol can have generic associated types?
- associatedtype Something<T> - associatedtype Something<T: Hashable> It's not mentioned, but I think it would be necessary at some point for completeness. On Thu, Mar 17, 2016 at 2:32 PM, Joe Groff via swift-evolution < [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]> 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. > > -Joe > > _______________________________________________ > 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
