[swift-evolution] [proposal] Generic type aliases

Dave Abrahams dabrahams at apple.com
Thu Mar 24 15:54:42 CDT 2016

on Wed Mar 16 2016, Joe Groff <swift-evolution at swift.org> wrote:

>> On Mar 16, 2016, at 5:02 PM, Chris Lattner <clattner at apple.com> wrote:
>> On Mar 16, 2016, at 4:56 PM, Joe Groff <jgroff at apple.com <mailto:jgroff at apple.com>> 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 :-)


More information about the swift-evolution mailing list