[swift-evolution] [proposal] Generic type aliases

[Howard Lovatt]

+1. It would be handy for:

typealias Vec3<T> = (T, T, T)
typealias Mat3x3<T> = (Vec3<T>, Vec3<T>, Vec3<T>)


  -- Howard.

On 10 March 2016 at 15:47, Chris Lattner via swift-evolution <
swift-evolution at swift.org> 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
> 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/20160310/b5d3a7c9/attachment.html>