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