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 <d...@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@swift.org
>> <mailto:swift-dev@swift.org>> wrote:
>>
>>
>>> On Sep 23, 2017, at 3:39 PM, David Zarzycki via swift-dev
>>> <swift-dev@swift.org <mailto:swift-dev@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@swift.org <mailto:swift-dev@swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-dev
>>
>> _______________________________________________
>> swift-dev mailing list
>> swift-dev@swift.org <mailto:swift-dev@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-dev
>
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
