> On Sep 25, 2017, at 3:41 PM, David Zarzycki <d...@znu.io> wrote:
>
>
>
>>> On Sep 25, 2017, at 18:23, Joe Groff <jgr...@apple.com> wrote:
>>>
>>>
>>>
>>> On Sep 25, 2017, at 1:04 PM, David Zarzycki <d...@znu.io> wrote:
>>>
>>>
>>>
>>>> On Sep 25, 2017, at 14:37, Joe Groff <jgr...@apple.com> wrote:
>>>>
>>>>
>>>>
>>>>> On Sep 23, 2017, at 10:36 PM, Robert Widmann via swift-dev
>>>>> <swift-dev@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.
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
