<div dir="ltr">On Tue, Jan 31, 2017 at 10:15 PM, Dave Abrahams <span dir="ltr">&lt;<a href="mailto:dabrahams@apple.com" target="_blank">dabrahams@apple.com</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
on Tue Jan 31 2017, Xiaodi Wu &lt;<a href="http://xiaodi.wu-AT-gmail.com" rel="noreferrer" target="_blank">xiaodi.wu-AT-gmail.com</a>&gt; wrote:<br>
<br>
&gt; On Tue, Jan 31, 2017 at 2:53 PM, Max Moiseev &lt;<a href="mailto:moiseev@apple.com">moiseev@apple.com</a>&gt; wrote:<br>
&gt;<br>
&gt;&gt; Hi Brent,<br>
&gt;&gt;<br>
&gt;&gt; Thanks a lot for your suggestions! After having discussed them with Dave,<br>
&gt;&gt; we came up with the following design that I personally like a lot.<br>
&gt;&gt;<br>
&gt;&gt; enum Overflowing { case .withOverflow }<br>
<br>
</span>I really dislike “Overflowing”; it seems to imply that there *will* be<br>
overflow.  How about<br>
<br>
  enum ReportingOverflow { case .reportingOverflow }</blockquote><div><br></div><div>Much better. Since the kind of reporting we&#39;re getting is the overflow flag, maybe even `FlaggingOverflow`?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
&gt;&gt;<br>
&gt;&gt; enum FullWidth { case .fullWidth }<br>
&gt;&gt;<br>
&gt;&gt; protocol FixedWidthInteger {<br>
&gt;&gt;   func adding(_ other: Self, _: Overflowing) -&gt; (partialValue: Self,<br>
&gt;&gt; overflow: ArithmeticOverflow)<br>
&gt;&gt;   func subtracting(_ other: Self, _: Overflowing) -&gt; (partialValue: Self,<br>
&gt;&gt; overflow: ArithmeticOverflow)<br>
&gt;&gt;   func multiplied(by other: Self, _: Overflowing) -&gt; (partialValue: Self,<br>
&gt;&gt; overflow: ArithmeticOverflow)<br>
&gt;&gt;   func divided(by other: Self, _: Overflowing) -&gt; (partialValue: Self,<br>
&gt;&gt; overflow: ArithmeticOverflow)<br>
&gt;&gt;<br>
&gt;&gt;   func multiplied(by other: Self, _: FullWidth) -&gt; DoubleWidth&lt;Self&gt;<br>
&gt;&gt;   func dividing(_ other: DoubleWidth&lt;Self&gt;, _: FullWidth) -&gt; (quotient:<br>
&gt;&gt; Self, remainder: Self)<br>
&gt;&gt; }<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; Call sites would look like:<br>
&gt;&gt;<br>
&gt;&gt; x.multiplied(by: y, .withOverflow) and x.multiplied(by: y, .fullWidth)<br>
&gt;&gt;<br>
&gt;&gt; a little different for the division:<br>
&gt;&gt;<br>
&gt;&gt; x.divided(by: y, .withOverflow) and y.dividing(x, .fullWidth)<br>
&gt;&gt;<br>
&gt;&gt; Note the inverse-ness of `dividing`, but the lack of the argument label<br>
&gt;&gt; makes it quite natural.<br>
&gt;&gt;<br>
&gt;<br>
&gt; This is an improvement in many ways, I think. However `.fullWidth` vs.<br>
&gt; `DoubleWidth` seems less than ideal.<br>
<br>
</span>IMO .fullWidth is an improvement over .DoubleWidth, at least for<br>
multiplication.  The latter just repeats type information, where the<br>
former tells you something about *how* the operation is to be performed.</blockquote><div><br></div><div>Sure, I buy that.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
&gt; I get that you can&#39;t reuse `DoubleWidth` for the single-case enum, but<br>
&gt; still.<br>
&gt;<br>
&gt; Now that * and &amp;* no longer used the `multiplied(by:)` spelling, is there a<br>
&gt; reason not to take advantage of overloading on the return value for these<br>
&gt; very specialized methods?<br>
&gt;<br>
&gt; ```<br>
&gt; protocol FixedWidthInteger {<br>
&gt;   typealias OverflowFlagging = (partialValue: Self, overflow:<br>
&gt; ArithmeticOverflow)<br>
&gt;   func multiplied(by other: Self) -&gt; OverflowFlagging<br>
&gt;   func multiplied(by other: Self) -&gt; DoubleWidth&lt;Self&gt;<br>
&gt; }<br>
&gt; ```<br>
&gt;<br>
&gt; You&#39;d then write `x.multiplied(by: y) as OverflowFlagging` and<br>
&gt; `x.multiplied(by: y) as DoubleWidth`<br>
<br>
</span>It&#39;s too subtle, IMO, and any place that type context is available to<br>
disambiguate the result, it<br>
<br>
             x.multiplied(by: y)<br>
<br>
will look like it should be rewritten as<br>
<br>
             x * y<br></blockquote><div><br></div><div>Fair point.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
&gt; With respect to `dividing` vs `divided`, IMO it&#39;d be a tricky name,<br>
&gt; especially for non-English speakers. The &quot;ed/ing&quot; rule has these suffixes<br>
&gt; used pretty interchangeably to indicate a non-mutating operation, depending<br>
&gt; on the vagaries of the English language, but we&#39;ve never had an &quot;ed&quot; and an<br>
&gt; &quot;ing&quot; used for completely different things on the same type, as far as I&#39;m<br>
&gt; aware. Why not move the `dividing` version to DoubleWidth, where it can be<br>
&gt; a proper `divided(by:)`?<br>
<br>
</span>Max and I discussed this; I&#39;ll let him answer.</blockquote><div><br></div><div>Awesome. Everything else is really stylistic, but I really think the linguistic quirk of `dividing` vs `divided` is suboptimal from a helping-people-write-correct-code standpoint.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888"><br>
<br>
--<br>
-Dave<br>
</font></span></blockquote></div><br></div></div>