[swift-evolution] [proposal] Generic type aliases

[Joe Groff]

> On Mar 16, 2016, at 4:42 PM, Chris Lattner <clattner at apple.com> wrote:
> 
>> 
>> On Mar 16, 2016, at 12:39 PM, Joe Groff <jgroff at apple.com <mailto: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>
> }

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

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