Then the split you want isn’t at the level of the ClosureExpr, it’s at the
level of the ApplyExpr. You should take a look at CSRanking and
penalize/remove overloads that have arguments whose “I have value semantics”
bits don’t match.
~Robert Widmann
> On Sep 24, 2017, at 8:01 AM, David Zarzycki <d...@znu.io> wrote:
>
> Well, for starters, a function with zero arguments/parameters can be value
> semantic. For example:
>
> func getMagicNumber() -> UInt64 {
> return 0x3A4B1C7539DA4922
> }
>
>
> Dave
>
>> On Sep 24, 2017, at 01:36, Robert Widmann via swift-dev <swift-dev@swift.org
>> <mailto: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’?
>>
>> ~Robert Widmann
>>
>>> On Sep 24, 2017, at 1:12 AM, David Zarzycki <d...@znu.io
>>> <mailto: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
>>>>> <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
>>>> <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
