> On Mar 16, 2016, at 12:39 PM, Joe Groff <[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>
}
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
