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> 
> 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
> https://lists.swift.org/mailman/listinfo/swift-dev

_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Reply via email to