<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Thanks John!<div class=""><br class=""></div><div class="">I’ll find a workaround or just punt on this QoI work for now.<br class=""><div><br class=""></div><div>Dave</div><div><br class=""><blockquote type="cite" class=""><div class="">On Sep 24, 2017, at 23:06, John McCall <<a href="mailto:rjmccall@apple.com" class="">rjmccall@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class="">On Sep 24, 2017, at 1:13 AM, David Zarzycki via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Robert,<div class=""><br class=""></div><div class="">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:</div><div class=""><br class=""></div><div class=""><font face="Courier" class="">// reference semantic context</font></div><div class=""><font face="Courier" class="">someValueTypeArray.sort({</font></div><div class=""><font face="Courier" class=""> // hasValueSemantics ExtInfo bit propagates from the</font></div><div class=""><font face="Courier" class=""> // </font><font face="Courier" class="">parameter type of sort()</font><span style="font-family: Courier;" class=""> to the ClosureExpr type</span></div><div class=""><span style="font-family: Courier;" class="">})</span></div><div class=""><div class=""><br class=""></div><div class="">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. :-)</div></div></div></div></blockquote><div class=""><br class=""></div>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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">John.</div><div class=""><br class=""></div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Dave</div><div class=""><br class=""></div><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Sep 23, 2017, at 20:11, Robert Widmann via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class=""><blockquote type="cite" class="">On Sep 23, 2017, at 3:39 PM, David Zarzycki via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:<br class=""><br class="">Hello,<br class=""><br class="">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).<br class=""></blockquote><br class="">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? <br class=""><br class="">~Robert Widmann<br class=""><br class=""><blockquote type="cite" class=""><br class="">Thanks,<br class="">Dave<br class="">_______________________________________________<br class="">swift-dev mailing list<br class=""><a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-dev" class="">https://lists.swift.org/mailman/listinfo/swift-dev</a><br class=""></blockquote><br class="">_______________________________________________<br class="">swift-dev mailing list<br class=""><a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-dev" class="">https://lists.swift.org/mailman/listinfo/swift-dev</a><br class=""></div></div></blockquote></div><br class=""></div></div>_______________________________________________<br class="">swift-dev mailing list<br class=""><a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-dev" class="">https://lists.swift.org/mailman/listinfo/swift-dev</a><br class=""></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></div></body></html>