> On Jul 12, 2016, at 12:58 AM, Charlie Monroe <[email protected]> > wrote: > > An example to keep in mind: > > let dict: [String : String] = ... > if dict["key"] == "value" { // String? == String > // Do something > } > > If I understand correctly, when the proposal is accepted, you'd need to do > something like: > > if let value = dict["key"], value == "value" { } > -- OR -- > if dict["key"] == Optional("value") { } > > It's not an end of the world, but makes life a bit more difficult and such > usecase should be kept in mind.
Yes, Jacob also pointed this out. Sometime later today I will push out an updated proposal that calls this out, and also discusses the overloads for equality and identity comparisons where one side is optional. I want to take another quick look at some of the changes I had to make to projects I looked at before I do so. Mark > > >> On Jul 12, 2016, at 9:09 AM, Mark Lacey via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> >>> On Jul 11, 2016, at 11:55 PM, Jacob Bandes-Storch <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Mark, >>> Thanks for writing this up. Just to clarify, will these still work if your >>> proposal is implemented? >>> >>> let x: Int? >>> let y: Int >>> struct NotEquatable {} >>> let z: NotEquatable? >>> >>> x == y; x != y >>> x == nil; x != nil >>> z == nil; z != nil >>> >>> I would hope that these continue to work. If any changes need to be made to >>> ensure that, please make sure they're included in the proposal too. >> >> The last four would work, but the first two (x == y and x != y) would not >> because they still involve coercing y to an optional. >> >> Similarly, === and !== on reference types where one is an optional would >> require coercing one side, and would not be accepted without an explicit >> cast using Optional(). >> >> I’m curious what the motivation is for further special casing these >> operators. They do occur more in practice than <, <=, >, >= (in fact most of >> the source updates I had to make were due to === and !==, with == and != a >> close second), but overall these are still quite uncommon from what I’ve >> seen. >> >> If you’d like I can certainly update the “alternatives considered” to >> include the suggestion that we add overloads for (T, T?) and (T?, T) for >> those four operators. >> >> Mark >> >>> >>> Jacob >>> >>> On Mon, Jul 11, 2016 at 9:35 PM, Mark Lacey <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>>> On Jul 11, 2016, at 9:12 PM, Chris Lattner via swift-evolution >>>> <[email protected] <mailto:[email protected]>> wrote: >>>> >>>> >>>>> On Jul 11, 2016, at 8:14 PM, Jacob Bandes-Storch via swift-evolution >>>>> <[email protected] <mailto:[email protected]>> 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. >>> >>> Mark >>> >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] <mailto:[email protected]> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> >>> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
