[swift-dev] A constraint system / type variable question

[David Zarzycki]

Thanks John!

I’ll find a workaround or just punt on this QoI work for now.

Dave

> On Sep 24, 2017, at 23:06, John McCall <rjmccall at apple.com> wrote:
> 
>> On Sep 24, 2017, at 1:13 AM, David Zarzycki via swift-dev <swift-dev at swift.org <mailto:swift-dev at 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 at swift.org <mailto:swift-dev at swift.org>> wrote:
>>> 
>>> 
>>>> On Sep 23, 2017, at 3:39 PM, David Zarzycki via swift-dev <swift-dev at swift.org <mailto:swift-dev at 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 at swift.org <mailto:swift-dev at swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-dev <https://lists.swift.org/mailman/listinfo/swift-dev>
>>> 
>>> _______________________________________________
>>> swift-dev mailing list
>>> swift-dev at swift.org <mailto:swift-dev at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-dev <https://lists.swift.org/mailman/listinfo/swift-dev>
>> 
>> _______________________________________________
>> swift-dev mailing list
>> swift-dev at swift.org <mailto:swift-dev at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-dev
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20170925/54396d35/attachment.html>