[swift-dev] A constraint system / type variable question
Robert Widmann
devteam.codafi at gmail.com
Sun Sep 24 00:36:00 CDT 2017
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’?
~Robert Widmann
> On Sep 24, 2017, at 1:12 AM, David Zarzycki <dave at znu.io> wrote:
>
> Hi Robert,
>
> As a prerequisite to some other hacking I’m doing, I have an experimental implementation of value semantics; where (among other details), all functions have a bit in ExtInfo that denotes whether the function has enforced value semantics or not. As a matter of polish, I’d like the following code to work:
>
> // reference semantic context
> someValueTypeArray.sort({
> // hasValueSemantics ExtInfo bit propagates from the
> // parameter type of sort() to the ClosureExpr type
> })
>
> Hence the desire to have the closure’s type be a disjunction between two FunctionTypes, one where the “hasValueSemantics” bit is set, and one where it is not. If there is a better way to do this, I’m open. :-)
>
> Thanks,
> Dave
>
>
>> On Sep 23, 2017, at 20:11, Robert Widmann via swift-dev <swift-dev at swift.org <mailto:swift-dev at swift.org>> wrote:
>>
>>
>>> On Sep 23, 2017, at 3:39 PM, David Zarzycki via swift-dev <swift-dev at swift.org <mailto:swift-dev at swift.org>> wrote:
>>>
>>> Hello,
>>>
>>> I’m trying to replace the explicit FunctionType returned by visitClosureExpr() in CSGen.cpp with a type variable; and ultimately a disjunction of two FunctionTypes with different ExtInfo flags set (one favored, one not).
>>
>> I really don’t recommend doing this. Even the current late-binding of a proper function type in closure inference is an artifact of the old function type representation that needs to go away (you’re probably running into parameter inference doing weird things which is a symptom of the larger problem). What does it matter that the two function types have different ExtInfo? What are you trying to do here?
>>
>> ~Robert Widmann
>>
>>>
>>> Thanks,
>>> Dave
>>> _______________________________________________
>>> swift-dev mailing list
>>> swift-dev at swift.org <mailto:swift-dev at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-dev
>>
>> _______________________________________________
>> swift-dev mailing list
>> swift-dev at swift.org <mailto:swift-dev at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20170924/d1535074/attachment.html>
More information about the swift-dev
mailing list