> On Sep 25, 2017, at 7:53 PM, David Zarzycki <d...@znu.io> wrote: > > > >> On Sep 25, 2017, at 21:59, Joe Groff via swift-dev <swift-dev@swift.org> >> wrote: >> >> >> >> 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. > > Ya, the “throws” subtyping and related conversion was useful to crib from, > but I don’t see how that helps the contextual ClosureExpr type scenario. > Unlike “throws” (and absent a contextual type), deducing the value semantic > nature of a closure requires type checking the body first. Am I missing > something? Is there a scenario that I can crib from where ExtInfo bits of the > contextual function type propagate onto the type of a ClosureExpr?
Checking whether a function throws or not also requires type-checking the body, since otherwise we don't know whether 'catch' blocks are exhaustive or whether 'try' subexpressions actually cover a failable operation. I'm definitely not an expert on the type checker, so I'm probably missing something, but it seems like the same problem. -Joe _______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
