[swift-evolution] [proposal] Generic type aliases

Chris Lattner clattner at apple.com
Wed Mar 16 18:42:21 CDT 2016

> On Mar 16, 2016, at 12:39 PM, Joe Groff <jgroff at apple.com> wrote:
>> On Mar 9, 2016, at 8:47 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160316/ce685698/attachment.html>

More information about the swift-evolution mailing list