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 < [email protected]> 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 < > [email protected]> wrote: > > > On Jul 11, 2016, at 9:54 PM, Chris Lattner <[email protected]> wrote: > > > On Jul 11, 2016, at 9:35 PM, Mark Lacey <[email protected]> wrote: > > > On Jul 11, 2016, at 9:12 PM, Chris Lattner via swift-evolution < > [email protected]> wrote: > > > On Jul 11, 2016, at 8:14 PM, Jacob Bandes-Storch via swift-evolution < > [email protected]> 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 > [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
