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