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 < [email protected]> wrote: > > On Jul 13, 2016, at 10:06 AM, Joe Groff via swift-evolution < > [email protected]> 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 < > [email protected]> 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 > >> [email protected] > >> https://lists.swift.org/mailman/listinfo/swift-evolution > > > > _______________________________________________ > > swift-evolution mailing list > > [email protected] > > https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
