> 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] <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.”
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
