[swift-evolution] [proposal] Generic type aliases
Adrian Zubarev
adrian.zubarev at devandartist.com
Mon Mar 21 05:16:05 CDT 2016
Will this feature allow something like this?
```swift
protocol SomeProtocol: class { /* some functions here */ }
typealias ProtoView<T: UIView where T: SomeProtocol> = T
```
I recently came across a design issue where I needed this type to be global instead of the generic top level of a class:
```swift
class A<T: UIView where T: SomeProtocol> { /*...*/ }
```
I couldn’t do something like this in my project and was forced to extend UIView with some kind of an extra backdoor protocol.
--
Adrian Zubarev
Sent with Airmail
Am 10. März 2016 bei 05:47:50, Chris Lattner via swift-evolution (swift-evolution at swift.org) schrieb:
Hi All,
I’ve started prototyping generic type aliases in master, but we’d like to run this through the evolution process for discussion. Comments and discussion are welcome. Here’s the start of the email thread for the actual formal proposal:
Introduction
This proposal aims to add generic typealiases to Swift.
Swift-evolution thread: <you are here>
Motivation
Generic typealiases are a somewhat obvious generalization of the existing Swift model for type aliases, which allow you to provide a name for an existing nominal generic type, or to provide a name for a non-nominal type (e.g. tuples, functions, etc) with generic parameters.
Proposed solution
The solution solution is straight-forward: allow type aliases to introduce type parameters, which are in scope for their definition. This allows one to express things like:
typealias StringDictionary<T> = Dictionary<String, T>
typealias IntFunction<T> = (T) -> Int
typealias MatchingTriple<T> = (T, T, T)
typealias BackwardTriple<T1,T2,T3> = (T3, T2, T1)
This is consistent with the rest of Swift’s approach to generics, and slots directly into the model.
Detailed design
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”.
Impact on existing code
This is a new feature, so there is no impact on existing code.
_______________________________________________
swift-evolution mailing list
swift-evolution at swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160321/07f855d3/attachment.html>
More information about the swift-evolution
mailing list