[swift-evolution] Enhanced existential types proposal discussion

[Matthew Johnson]

Sent from my iPad

> On May 18, 2016, at 10:25 AM, Austin Zheng via swift-evolution <swift-evolution at swift.org> 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 <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
>> 
> 
> _______________________________________________
> 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/af68fe03/attachment.html>