> On Sep 24, 2017, at 1:13 AM, David Zarzycki via swift-dev
> <swift-dev@swift.org> 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. :-)
The working plan with closure type-checking is that we'll add a "this is a
closure type" constraint to the type-checker where, instead of having to pick a
concretely-structured function type during CSGen, we'll create a fresh type
variable and say that its type is required to be structured compatibly with
whatever information we've derived from the closure. Contextual information
would then naturally flow from the context to the closure's type. The
constraint solver would default the function type from the encoded closure
structure of the constraint if it could prove that no other constraint applied.
If that was implemented, we'd be able to propagate arbitrary function-type
structure from the context instead of having to eagerly create highly-complex
constraint systems whenever we encountered a closure.
John.
>
> 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
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
