I would love to have this feature. I've tried to do this before in Swift, assuming it was supported. I'm sure I'm not the only one.
> On Mar 9, 2016, at 11:47 PM, Chris Lattner via swift-evolution > <[email protected]> wrote: > > 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
