[swift-evolution] [Review] SE-0067: Enhanced Floating Point Protocols

Xiaodi Wu xiaodi.wu at gmail.com
Wed Apr 20 16:12:04 CDT 2016


Likewise, FWIW, +0 is ordered above -0 but is equal to it, so less than or
equal to is not the same thing as being ordered at or below.
On Wed, Apr 20, 2016 at 16:05 Xiaodi Wu <xiaodi.wu at gmail.com> wrote:

> Less than or equal to is not the same as not greater than, because two
> unordered values are not less than or equal to and also not greater than.
> On Wed, Apr 20, 2016 at 15:51 plx via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> FWIW, you can avoid the multiple-preposition issue it differently:
>>
>> - isLessThanOrEqual(to:) => isNotGreaterThan(_:), isAtOrBelow(_:), etc.
>>
>> …neither of which I can claim to really like, but such possibilities
>> exist.
>>
>> Offering in case there's a better phrasing along similar lines.
>>
>> On Apr 20, 2016, at 3:08 PM, Xiaodi Wu via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>> I'm saying something else. The preposition that goes with "less" is
>> "than," while "to" goes only with "equal." By making "to" a parameter label
>> you've got {less than or equal} to, which is inelegant because the label
>> cannot be distributed to both parts--i.e. one cannot say "less than to or
>> equal to."
>>
>> Put another way, I could just as well rewrite the method as
>> `equalToOrLess(than:)`. Now, the parameter is labeled "than" instead of
>> "to," yet the parameter serves the same purpose. Thus, I argue that the
>> proposed method name may meet the letter of the Swift guidelines but is
>> awkward.
>>
>> On Wed, Apr 20, 2016 at 14:44 Dave Abrahams via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>>>
>>> on Tue Apr 19 2016, Xiaodi Wu <swift-evolution at swift.org> wrote:
>>>
>>> >  * What is your evaluation of the proposal?
>>> >
>>> > +1 in intent. Specifics require further refinement. For example:
>>> >
>>> > Internal inconsistencies in capitalization:
>>> > * `signalingNaN` but `isSignalingNan` and `isNan`
>>> >
>>> > Parameter labels, or whatever they're called now, do not reflect newly
>>> > adopted Swift syntax in SE-0046:
>>> > * `static func maximum(x: Self, _ y: Self) -> Self` should be `static
>>> > func maximum(_ x: Self, _ y: Self) -> Self`, etc.
>>> >
>>> > Infelicitous use of prepositions to conform superficially to new
>>> > naming guidelines:
>>> > * `isEqual(to:)` is fine, but for consistency there's
>>> > `isLessThanOrEqual(to:)`, which is not fine, because the preposition
>>> > "to" applies only to "equal" and not to "less than"
>>>
>>> That seems like a huge stretch to me.  Are you claiming it's wrong to
>>> say “x is less than or equal to y,” or are you saying something else?
>>>
>>> --
>>> Dave
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160420/41f239a9/attachment.html>


More information about the swift-evolution mailing list