The problem with moving divided(by:) to DoubleWidth<T> is that <T> over there.

When `dividing(_:)` is on the FixedWidthInteger conforming type, Self is known 
and it is possible to implement this operation efficiently. If it moves to the 
DoubleWidth<T>, because T is just “something that conforms to 
FixedWidthInteger” in order to be efficient, it has to delegate the 
functionality to something in T. So there *has to* be something in 
FixedWidthInteger to play that role.

Since the dividend is not Self in case of full-wdith division, we either flip 
the order of arguments and make take a shape of regular division with overflow, 
or we make it static as it is currently defined in the proposal.
Argument for the `dividing(_:)` is similarity to the rest of the operations, 
and if you’re doing this, you likely know what you’re doing… Unfriendliness to 
non-native English speakers was actually my first argument against it. But 
along with the lack of argument label, I think it’s OK.
The static fullWidthDivide(_:_:) or divide(_:_:_:FullWidth) are more natural 
with regards to the order of arguments, but really stand out of the rest of the 
API. If we agree on multiplied(by:_:FullWidth), the static full-width division 
would be the only static method in the protocol.

Max


> On Jan 31, 2017, at 8:32 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
> 
> > With respect to `dividing` vs `divided`, IMO it'd be a tricky name,
> > especially for non-English speakers. The "ed/ing" rule has these suffixes
> > used pretty interchangeably to indicate a non-mutating operation, depending
> > on the vagaries of the English language, but we've never had an "ed" and an
> > "ing" used for completely different things on the same type, as far as I'm
> > aware. Why not move the `dividing` version to DoubleWidth, where it can be
> > a proper `divided(by:)`?
> 
> Max and I discussed this; I'll let him answer.
> 
> 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.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to