> On Mar 16, 2016, at 4:42 PM, Chris Lattner <[email protected]> wrote:
>
>>
>> On Mar 16, 2016, at 12:39 PM, Joe Groff <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>
>>> On Mar 9, 2016, at 8:47 PM, Chris Lattner via swift-evolution
>>> <[email protected] <mailto:[email protected]>> wrote:
>>>
>>> This is a minimal proposal for introducing type aliases into Swift, and
>>> intentionally chooses to keep them limited to being “aliases”. As such,
>>> additional constraints are not allowed in this base proposal, e.g. you
>>> can’t write:
>>>
>>> typealias StringDictionary<T where T : Hashable> = Dictionary<String, T>
>>>
>>> Otherwise, generic type aliases follow the model of type aliases and the
>>> precedent of the other generic declarations in Swift. For example, they
>>> allow the usual access control features that type aliases support.
>>> Similarly, like non-generic type aliases, generic type aliases cannot be
>>> “resilient”.
>>
>> Can we at least infer existing constraints from the aliased type? For
>> example, in something like:
>>
>> typealias FakeSet<T> = Dictionary<T, ()>
>>
>> you'd need to propagate the `T: Hashable` constraint from `Dictionary`'s
>> first parameter to the typealias for it to be sound.
>
> Since writing the proposal up (and since discussing it with you), I have come
> around to disagree with the proposal as I wrote it. Specifically, I think
> that constraints of the aliasee *should* be specified in the typealias
> declaration. You should be required to write:
>
> typealias DictionaryOfString<T : Hashable> = Dictionary<T, String>
>
> 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.
-Joe
> First, we want the source code for the decl to be obvious and self describing.
>
> Second, this simplifies the type checker, by eliminating the need for it to
> do global analysis.
>
> -Chris
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
