[swift-evolution] [proposal] Generic type aliases

[Andrew Bennett]

Big +1 on this proposal from me.

Does this proposal allow a protocol can have generic associated types?

   - associatedtype Something<T>
   - associatedtype Something<T: Hashable>

It's not mentioned, but I think it would be necessary at some point for
completeness.


On Thu, Mar 17, 2016 at 2:32 PM, Joe Groff via swift-evolution <
swift-evolution at swift.org> wrote:

>
> On Mar 16, 2016, at 5:02 PM, Chris Lattner <clattner at apple.com> wrote:
>
> On Mar 16, 2016, at 4:56 PM, Joe Groff <jgroff at apple.com> wrote:
>
> 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.
>
>
> I consider the RHS of the typealias to be the “body” of the type alias,
> and parameters to be part of the “signature” of the funcdecl.
>
>
> I'm OK starting with the base design that constraints have to be explicit.
> My gut tells me though that `typealias` is close enough syntactically to
> `var` that many people will expect the inference to occur, but we can
> always add it later.
>
> -Joe
>
> _______________________________________________
> 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/20160317/68018d27/attachment.html>