Sent from my iPad
> On May 18, 2016, at 10:25 AM, Austin Zheng via swift-evolution > <[email protected]> wrote: > > 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. I agree about value types. I'm not sure what benefit that provides. What we really need here is the ability to constrain value semantics. Simply constraining to a value type does not do that (a struct can have a class property and use it in a way that violates value semantics). Dave A and I have had a pretty lengthy discussion of desirable se,antic guarantees recently. > > 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
