[swift-evolution] [Review] SE-0123: Disallow coercion to optionals in operator arguments

[Nevin Brackett-Rozinsky]

I concur with Joe Groff and John McCall, this proposal does not seem to be
the right approach.

What I would really like is the complete elimination of implicit coercion
to Optional (implicit type conversions are not Swifty!) and the
simultaneous introduction of a simple notation for doing so explicitly.

If we can make it play nice with optional chaining, then a postfix `?`
operator is the natural choice: `(42?, "babel fish"?, mattressSwamp?)`
would be a tuple of optionals, and `(1, 2, 3)?` an optional tuple.

Nevin


On Wed, Jul 13, 2016 at 1:16 PM, John McCall via swift-evolution <
swift-evolution at swift.org> wrote:

> > On Jul 13, 2016, at 10:06 AM, Joe Groff via swift-evolution <
> swift-evolution at swift.org> wrote:
> > -1. This feels like a band-aid rather than a well-considered fix to the
> issues raised in the proposal. I don't see what makes operators as a class
> of functions more or less susceptible to these surprising optional upcasts.
> Removing the comparison operators for optionals will resolve the issue with
> '<', and if we're concerned about '??', an unavailable overload for ??(T,
> T) could address that specific issue. Optional promotion in operators is
> clearly useful in many cases, as the proposal itself concedes by
> special-case exempting the assignment operator from the restriction and
> proposing the addition of more than a dozen overloads to restore the
> equivalent of explicit promotion behavior for specific operators, and that
> doing so accepts other undesirable formulations like 'nonOptional == nil'.
> This proposal doesn't make a compelling case that being an operator is the
> correct criterion to disable optional promotion.
>
> Agreed.  To me, the right solution is some attribute to suppress promotion
> for specific arguments.
>
> When we get to decl-based overload resolution, this will become
> straightforward to implement.
>
> John.
>
> >
> > -Joe
> >
> >> On Jul 12, 2016, at 10:25 PM, Chris Lattner via swift-evolution <
> swift-evolution at swift.org> wrote:
> >>
> >> Hello Swift community,
> >>
> >> The review of "SE-0123: Disallow coercion to optionals in operator
> arguments" begins now and runs through July 19. The proposal is available
> here:
> >>
> >>
> https://github.com/apple/swift-evolution/blob/master/proposals/0123-disallow-value-to-optional-coercion-in-operator-arguments.md
> >>
> >> Reviews are an important part of the Swift evolution process. All
> reviews should be sent to the swift-evolution mailing list at
> >>
> >>      https://lists.swift.org/mailman/listinfo/swift-evolution
> >>
> >> or, if you would like to keep your feedback private, directly to the
> review manager.
> >>
> >> What goes into a review?
> >>
> >> The goal of the review process is to improve the proposal under review
> through constructive criticism and contribute to the direction of Swift.
> When writing your review, here are some questions you might want to answer
> in your review:
> >>
> >>      * What is your evaluation of the proposal?
> >>      * Is the problem being addressed significant enough to warrant a
> change to Swift?
> >>      * Does this proposal fit well with the feel and direction of Swift?
> >>      * If you have used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?
> >>      * How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
> >>
> >> More information about the Swift evolution process is available at
> >>
> >>      https://github.com/apple/swift-evolution/blob/master/process.md
> >>
> >> Thank you,
> >>
> >> -Chris Lattner
> >> Review Manager
> >>
> >> _______________________________________________
> >> 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/20160713/b4ae457e/attachment.html>