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 > <[email protected]> wrote: > > >> On Jul 11, 2016, at 9:54 PM, Chris Lattner <[email protected] >> <mailto:[email protected]>> wrote: >> >>> >>> On 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. >> >> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
