[swift-evolution] Optional comparison operators

[Jacob Bandes-Storch]

David,
The proposal Mark is working on doesn't remove the operators which accept
optional values. It simply removes the ability to pass non-optional values
to them without explicit casting/coercion. In that example y doesn't need
to be coerced.

I'm currently writing up a separate proposal to remove these operators. The
two issues are largely orthogonal.

Jacob

On Mon, Jul 11, 2016 at 11:49 PM, David Hart via swift-evolution <
swift-evolution at swift.org> wrote:

> There’s something I don’t understand about the proposal. How can the
> following code still be valid if the proposal is accepted:
>
> let x: Int! = 5
> let y: Int? = 7
> print(x < y) // true
>
> Isn’t there going to be a problem coercing y?
>
> David.
>
> On 12 Jul 2016, at 08:22, Mark Lacey via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
> On Jul 11, 2016, at 9:54 PM, Chris Lattner <clattner at apple.com> wrote:
>
>
> 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> wrote:
>
>
> On Jul 11, 2016, at 8:14 PM, Jacob Bandes-Storch via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> You'd have to unwrap it, or use the ??/==/!= operators:
> 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
>
> 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.”
>
>
> Thanks for the great feedback. I have most of it addressed, but I’m not
> sure what you’re referring to with “If this is relating to implementation
> details of the standard library…”? Do you mean the functions I called out
> that need to be added?
>
> I can remove that, but I thought it was worth calling out despite the fact
> that they are just overloads. If it’s not necessary to do so, I’ll delete
> that section (although there aren’t many details left in the “Detailed
> design” at that point).
>
> Mark
>
>
> 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
>
>
> _______________________________________________
> 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/20160711/3691b58e/attachment.html>