[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 :-)
--
Dave
More information about the swift-evolution
mailing list