[swift-dev] A constraint system / type variable question

[Joe Groff]

> On Sep 25, 2017, at 3:41 PM, David Zarzycki <dave at znu.io> wrote:
> 
> 
> 
>>> On Sep 25, 2017, at 18:23, Joe Groff <jgroff at apple.com> wrote:
>>> 
>>> 
>>> 
>>> On Sep 25, 2017, at 1:04 PM, David Zarzycki <dave at znu.io> wrote:
>>> 
>>> 
>>> 
>>>> On Sep 25, 2017, at 14:37, Joe Groff <jgroff at apple.com> wrote:
>>>> 
>>>> 
>>>> 
>>>>> On Sep 23, 2017, at 10:36 PM, Robert Widmann via swift-dev <swift-dev at swift.org> wrote:
>>>>> 
>>>>> Why is the arrow carrying the “Has Value Semantics Bit” rather than it being part of a protocol composition on an argument type, or a convention bit on the parameter like ‘inout’?
>>>> 
>>>> Value semantics is a property of operations, not really of types. I would say the function arrow is the right place for it, since not-value-semantics propagates in the same manner as an effect like "throws". Dave, you might in fact look at how 'throws' type checking is implemented as a model for what you're trying to do.
>>> 
>>> Hi Joe,
>>> 
>>> In fact, I tried to replicate the “closureCanThrow()” logic before emailing this list, but that didn’t work due to a chicken-and-egg problem that arrises between when a ClosureExpr's body is type checked and knowing the type of the ClosureExpr. In other words, a closure has value semantics iff all operations within it have value semantics.
>>> 
>>> As I wrote earlier in this email thread, the “value semantics” implementation I’m working on is sufficient for the research that I’m doing. That being said, I took some shortcuts to get it working and the closure type shortcut bothered me the most. That is why I emailed this list about how to propagate the contextual ExtInfo bit onto the closure type. Based on John’s helpful email, I think I’ll just live with the shortcuts I made for now.
>> 
>> If you have something working well enough for your prototype, then great. If you do decide to look at this again, I think it might be easier to flip the polarity of the check—a closure is not-value-semantics if it does anything that's not-value-semantics—which should make it the exact same kind of problem as `throws` propagation.
> 
> Thanks. FWIW – I thought about that because ExtInfo has a bias towards “false” as the default for flags within it, and that forced me to contemplate what the default semantics should be. Unfortunately, either default doesn’t work for the same reason: the ExtInfo bits are stored in the type, but closure body type checking is done after the type of the closure is needed.

The other thing `throws` does is establish a subtype relationship from nonthrowing to throwing functions, so if analysis determines a closure doesn't throw, but we later determine that we need a throwing one, we can implicitly convert. I think it'd be appropriate to allow a similar conversion from pure-value-semantics to non-value-semantics, and I think that'd address your issue.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20170925/818b9181/attachment.html>