Here is one type of mistake that I made long after that I should have
known better:
[snip]
If you find yourself in danger of forgetting that a value is optional, you
can always adopt a naming convention that makes it apparent. That would
have the same effect as requiring a postfix-? on optional identifiers,
except that it's voluntary.
That would have helped not at all in the example you snipped. But let's not
get hung up on that, I'd rather establish how useful it is to have <, <=, >
and >= cover optional values.
Personally, I find the ability to compare optionals to be very valuable,
almost as valuable as the ability to use == with optionals (which I doubt
anyone will argue is a misfeature).
I have been trying to come up with situations where you would want to
compare two values, knowing that one or both may be nil, with <, <=, > or
>=. Other than as for sorting, I can't think of much. I doubt the Swift
team explicitly made this possible without good reason, so I must be
missing something.
Could you please share some examples? It doesn't necessarily have to be
code, just explain the context where this is valuable.
Sorting is a common one. Another example is just cases where I need to
compare two numbers and at least one number may have been generated by an
optional process. For example:
if optAry?.count > 3 {
Instead of:
if let count = optAry?.count where count > 3 {
Which is twice as long, which of course is inconvenient if you do this a
lot, and you don't need the unwrapped value again. A distinct comparison
operator for optional values could solve that.
This can work with non-numeric values too, though usually if I'm
comparing non-numeric values with < then I'm doing some variant on sorting,
which we've already addressed. For example, from my current codebase I find
let sortedJSON = responsesJSON.sort { a, b in
let a_name = a["name"] as? String
let b_name = b["name"] as? String
return a_name?.lowercaseString < b_name?.lowercaseString
}
Instead of:
let sortedJSON = responsesJSON.sort { a, b in
let a_name = a["name"] as? String ?? ""
let b_name = b["name"] as? String ?? ""
return a_name.lowercaseString < b_name.lowercaseString
}
Which I think anyone can accept (except that I find ?? to be an eyesore,
but that is a different topic.)
Please note that I'm absolutely not arguing for the suggestion that started
this thread. I just want to understand if it really is necessary to
overload all the comparison operators for (T?, T?) in the first place.
(although were I to rewrite this code I'd switch to using
···
On Mon, Dec 7, 2015 at 8:32 PM, Kevin Ballard <kevin@sb.org> wrote:
On Mon, Dec 7, 2015, at 03:48 AM, Per Melin wrote:
caseInsensitiveCompare() as lowercaseString is needlessly allocating a new
string, but it demonstrates the idea)
I know somewhere in another project I used < with optionals to great
effect for a non-sorting purpose, but I don't remember where to find it
anymore.
In general, my feeling here is that supporting == and < on optionals is
just a specific case of a generally desired property that is Equatable and
Comparable should be supported on all types that are simple wrappers around
existing Equatable/Comparable types. I know this isn't well-defined, but I
mean that since Optional is really just taking the set of values for a type
and adding one additional value, if the type is Comparable/Equatable,
there's an obvious way to define this new inhabiting value as being
Comparable/Equatable with the type, and so it should be done. Similarly, I
think that if I have a tuple (T, U) where both T and U are
Comparable/Equatable, the tuple itself should be (where the Comparable
implementation compares the T value first, and if it's equal then compares
the U value). And any larger tuple where every component element is
Comparable/Equatable should also be Comparable/Equatable. I should also be
able to opt-in to this kind of automatic Comparable/Equatable generation
for structs. I should also be able to get this on other enums where only
one enum variant has associated values, and the associated values are
comparable/equatable (i.e. a generalization of Optional).
-Kevin