<div dir="ltr">On Tue, Jan 31, 2017 at 10:15 PM, Dave Abrahams <span dir="ltr"><<a href="mailto:dabrahams@apple.com" target="_blank">dabrahams@apple.com</a>></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 <<a href="http://xiaodi.wu-AT-gmail.com" rel="noreferrer" target="_blank">xiaodi.wu-AT-gmail.com</a>> wrote:<br>
<br>
> On Tue, Jan 31, 2017 at 2:53 PM, Max Moiseev <<a href="mailto:moiseev@apple.com">moiseev@apple.com</a>> wrote:<br>
><br>
>> Hi Brent,<br>
>><br>
>> Thanks a lot for your suggestions! After having discussed them with Dave,<br>
>> we came up with the following design that I personally like a lot.<br>
>><br>
>> 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'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>
>><br>
>> enum FullWidth { case .fullWidth }<br>
>><br>
>> protocol FixedWidthInteger {<br>
>> func adding(_ other: Self, _: Overflowing) -> (partialValue: Self,<br>
>> overflow: ArithmeticOverflow)<br>
>> func subtracting(_ other: Self, _: Overflowing) -> (partialValue: Self,<br>
>> overflow: ArithmeticOverflow)<br>
>> func multiplied(by other: Self, _: Overflowing) -> (partialValue: Self,<br>
>> overflow: ArithmeticOverflow)<br>
>> func divided(by other: Self, _: Overflowing) -> (partialValue: Self,<br>
>> overflow: ArithmeticOverflow)<br>
>><br>
>> func multiplied(by other: Self, _: FullWidth) -> DoubleWidth<Self><br>
>> func dividing(_ other: DoubleWidth<Self>, _: FullWidth) -> (quotient:<br>
>> Self, remainder: Self)<br>
>> }<br>
>><br>
>><br>
>> Call sites would look like:<br>
>><br>
>> x.multiplied(by: y, .withOverflow) and x.multiplied(by: y, .fullWidth)<br>
>><br>
>> a little different for the division:<br>
>><br>
>> x.divided(by: y, .withOverflow) and y.dividing(x, .fullWidth)<br>
>><br>
>> Note the inverse-ness of `dividing`, but the lack of the argument label<br>
>> makes it quite natural.<br>
>><br>
><br>
> This is an improvement in many ways, I think. However `.fullWidth` vs.<br>
> `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="">
> I get that you can't reuse `DoubleWidth` for the single-case enum, but<br>
> still.<br>
><br>
> Now that * and &* no longer used the `multiplied(by:)` spelling, is there a<br>
> reason not to take advantage of overloading on the return value for these<br>
> very specialized methods?<br>
><br>
> ```<br>
> protocol FixedWidthInteger {<br>
> typealias OverflowFlagging = (partialValue: Self, overflow:<br>
> ArithmeticOverflow)<br>
> func multiplied(by other: Self) -> OverflowFlagging<br>
> func multiplied(by other: Self) -> DoubleWidth<Self><br>
> }<br>
> ```<br>
><br>
> You'd then write `x.multiplied(by: y) as OverflowFlagging` and<br>
> `x.multiplied(by: y) as DoubleWidth`<br>
<br>
</span>It'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="">
> With respect to `dividing` vs `divided`, IMO it'd be a tricky name,<br>
> especially for non-English speakers. The "ed/ing" rule has these suffixes<br>
> used pretty interchangeably to indicate a non-mutating operation, depending<br>
> on the vagaries of the English language, but we've never had an "ed" and an<br>
> "ing" used for completely different things on the same type, as far as I'm<br>
> aware. Why not move the `dividing` version to DoubleWidth, where it can be<br>
> a proper `divided(by:)`?<br>
<br>
</span>Max and I discussed this; I'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>