<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On Dec 17, 2015, at 12:33 AM, Matthew Johnson &lt;<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</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=""><div class=""><blockquote type="cite" class=""><div 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=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="">If you remove that overload your code will fail to compile. &nbsp;This is because the dot abbreviation is context sensitive. &nbsp;It only works when the type system knows the type the expression is expected to produce.</div></div></div></blockquote><div class=""><br class=""></div><div class="">Of course :) And if the overload stays and your suggested syntax were added, it would be ambiguous and also fail to compile.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">This is not true. &nbsp;They would have different types and therefore would not be ambiguous.</div></div></div></div></blockquote><div><br class=""></div><div>It's true in my example, but my example is an unlikely, type-ambiguous situation and is unlikely to occur in usage.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">But it’s not central to your position anyway since you are opposed on the grounds of potential for confusion rather than actual ambiguity. &nbsp;:) &nbsp;That is a fair and reasonable position with or without ambiguity.</div></div></div></div></blockquote></div><br class=""><div class="">I'm not opposed to the idea if it has broad applications and the type resolution is predictable. I think I'm probably doing a bad job of predicting.</div><div class=""><br class=""></div><div class="">Stephen</div></body></html>