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

[Joe Groff]

> 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.

-Joe