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 < [email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
