[swift-evolution] Enhanced existential types proposal discussion
austinzheng at gmail.com
Wed May 18 10:25:21 CDT 2016
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
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
> `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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution