[swift-evolution] Optional comparison operators

[Chris Lattner]

> On Jul 11, 2016, at 9:35 PM, Mark Lacey <mark.lacey at apple.com> wrote:
> 
> 
>> On Jul 11, 2016, at 9:12 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> 
>>> On Jul 11, 2016, at 8:14 PM, Jacob Bandes-Storch via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> You'd have to unwrap it, or use the ??/==/!= operators: https://gist.github.com/jtbandes/9d88cc83ceceb6c62f38 <https://gist.github.com/jtbandes/9d88cc83ceceb6c62f38>
>>> 
>>> I'd be okay with </<=/>/>= returning Bool?, as I suggested in an older email (which somehow didn't make it to gmane's archive, but it's quoted in some other messages <http://thread.gmane.org/gmane.comp.lang.swift.evolution/10095>). I think it would be more convenient in some cases than unwrapping the individual values before comparing them.
>> 
>> I’d be strongly opposed to those operator returning “Bool?”.  Doing so would prevent conforming to Comparable and would be extremely surprising.
>> 
>> -Chris
> 
> I just pushed the current draft of the proposal: https://github.com/rudkx/swift-evolution/blob/eliminate-value-to-optional-coercion/proposals/0000-disallow-value-to-optional-coercion-in-operator-arguments.md <https://github.com/rudkx/swift-evolution/blob/eliminate-value-to-optional-coercion/proposals/0000-disallow-value-to-optional-coercion-in-operator-arguments.md>
> 
> I haven’t addressed removal of the ordered comparison operators. I suspect this should be a separate proposal, but I can roll that into this one if it’s desired.
> 
> I’ll update the proposal as the discussion continues until it’s selected for review.

I think it makes sense to keep removal of the non-equality comparisons a separate proposal.

Here are some nit-picky comments:

I’d suggest adding quotes:

… by making the notion of “having" or "not having" a value explicit. 

Missing a let/var before the first x in:

func returnsOptional() -> Int? {
  x: Int = ...
  return x
}


I would move “Proposed Solution” before “Motivation” and just call it “Proposal”.  Otherwise the motivation section doesn’t make sense to read in order.


I’d add to this:
"Both of these examples represent cases where the silent behavior could potentially hide bugs or confuse readers of the code.”  

… “, it would be better to reject the code as a type error."


If this is relating to implementation details of the standard library, then it should be omitted from the proposal.  The following paragraph also makes sense to revise if you drop this:
"Additionally the standard library has approximately a half a dozen locations where optionals are compared to non-optional values which will need to be updated to explicitly cast one operand to an optional.”


In this paragraph, I’d recommend changing the wording to be specific and opinionated (saying that “Optional” is the right answer).  If you want to raise specific alternatives for consideration, please add it to “alternatives considered” at the end:
"This conversion can currently be accomplished by using Optional() (preferable) or alternately .some(). We could also consider adding a new top-level function for this purpose, but unless it provides additional clarity, it seems like Optional() is reasonable and quite prominent."

Keeping the body of the proposal opinionated makes the review periods more useful because people know what is specifically being proposed.



"In a survey of six projects” -> Can you explicitly share the name of any of the projects?

Otherwise, LGTM.  When you’re happy with it, please submit a PR for swift-evolution repo, I’ll review managerize it,

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160711/0535723f/attachment.html>