<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="">Well, for starters, a function with zero arguments/parameters can be value semantic. For example:<div class=""><br class=""></div><div class=""><font face="Courier" class="">func getMagicNumber() -&gt; UInt64 {</font></div><div class=""><font face="Courier" class="">&nbsp; return 0x3A4B1C7539DA4922</font></div><div class=""><font face="Courier" class="">}</font></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Dave</div><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Sep 24, 2017, at 01:36, Robert Widmann via swift-dev &lt;<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>&gt; 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="">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’?<div class=""><div class=""><br class=""></div><div class="">~Robert Widmann<br class=""><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Sep 24, 2017, at 1:12 AM, David Zarzycki &lt;<a href="mailto:dave@znu.io" class="">dave@znu.io</a>&gt; 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; 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="">&nbsp; // hasValueSemantics ExtInfo bit&nbsp;propagates&nbsp;from the</font></div><div class=""><font face="Courier" class="">&nbsp; //&nbsp;</font><font face="Courier" class="">parameter type of sort()</font><span style="font-family: Courier;" class="">&nbsp;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 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 &lt;<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>&gt; 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 &lt;<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>&gt; 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. &nbsp;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). &nbsp;What does it matter that the two function types have different ExtInfo? &nbsp;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></div></blockquote></div><br class=""></div></div></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="">https://lists.swift.org/mailman/listinfo/swift-dev<br class=""></div></blockquote></div><br class=""></div></body></html>