[swift-evolution] Enhanced existential types proposal discussion

[Austin Zheng]

You should definitely submit your proposal first. I'll review your nesting
rules later. f your proposal is accepted I will edit mine to match.

Allowing value types belong in a separate proposal; I think this is
something people would want to discuss on their own merits. For example,
the `class` keyword already exists, and can be used in several places to
force something to be a class. People would want similar value type
keywords to also work everywhere `class` does, not only in a composite type
declaration.

Austin

On Wed, May 18, 2016 at 6:49 AM, Adrian Zubarev via swift-evolution <
swift-evolution at swift.org> wrote:

> I added a note to my proposal which makes it clear that the `Any<>` I
> proposed represents the simple/base form that Swift 3 should integrate, if
> accepted. Later `Any<>` could be enhanced without any breaking changes.
>
> I’m not sure if your and my nesting rules do fit together, we might
> reconsider mine before the pull request is accepted.
>
> - Also I don’t see the point why `Any<Any<ProtocolA, ProtocolB>>` this is
> illegal!?
>
> `Any<>` proposed by me will allow that, even it its useless form the point
> of the readers view. This type is inferred to `Any<ProtocolA, ProtocolB>`.
>
> Why do you not allow value types in your proposal?
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> _______________________________________________
> 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/20160518/81f79217/attachment.html>