<div dir="ltr">David,<div>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.</div><div><br></div><div>I'm currently writing up a separate proposal to remove these operators. The two issues are largely orthogonal.</div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Jacob<br></div></div></div></div>
<br><div class="gmail_quote">On Mon, Jul 11, 2016 at 11:49 PM, David Hart via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">There’s something I don’t understand about the proposal. How can the following code still be valid if the proposal is accepted:<div><br></div><div>let x: Int! = 5<br>let y: Int? = 7<br>print(x < y) // true</div><div><br></div><div>Isn’t there going to be a problem coercing y?</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>David.</div></font></span><div><br><div><blockquote type="cite"><div><div class="h5"><div>On 12 Jul 2016, at 08:22, Mark Lacey via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br></div></div><div><div><div class="h5"><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On Jul 11, 2016, at 9:54 PM, Chris Lattner <<a href="mailto:clattner@apple.com" target="_blank">clattner@apple.com</a>> wrote:</div><br><div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><blockquote type="cite"><div><br>On Jul 11, 2016, at 9:35 PM, Mark Lacey <<a href="mailto:mark.lacey@apple.com" target="_blank">mark.lacey@apple.com</a>> wrote:</div><br><div><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On Jul 11, 2016, at 9:12 PM, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br><div><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On Jul 11, 2016, at 8:14 PM, Jacob Bandes-Storch via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br><div><div dir="ltr"><div>You'd have to unwrap it, or use the ??/==/!= operators: <a href="https://gist.github.com/jtbandes/9d88cc83ceceb6c62f38" target="_blank">https://gist.github.com/jtbandes/9d88cc83ceceb6c62f38</a></div><div><br></div><div>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<span> </span><a href="http://thread.gmane.org/gmane.comp.lang.swift.evolution/10095" target="_blank">some other messages</a>). I think it would be more convenient in some cases than unwrapping the individual values before comparing them.</div></div></div></blockquote><br></div><div>I’d be strongly opposed to those operator returning “Bool?”. Doing so would prevent conforming to Comparable and would be extremely surprising.</div><div><br></div><div>-Chris</div></div></div></blockquote><div><br></div>I just pushed the current draft of the proposal: <a href="https://github.com/rudkx/swift-evolution/blob/eliminate-value-to-optional-coercion/proposals/0000-disallow-value-to-optional-coercion-in-operator-arguments.md" target="_blank">https://github.com/rudkx/swift-evolution/blob/eliminate-value-to-optional-coercion/proposals/0000-disallow-value-to-optional-coercion-in-operator-arguments.md</a></div><div><br></div><div>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.</div><div><br></div><div>I’ll update the proposal as the discussion continues until it’s selected for review.</div></div></div></blockquote><br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">I think it makes sense to keep removal of the non-equality comparisons a separate proposal.</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">Here are some nit-picky comments:</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">I’d suggest adding quotes:</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">… by making the notion of “having" or "not having" a value explicit. </div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">Missing a let/var before the first x in:</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><pre style="font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:14px;margin-top:0px;margin-bottom:0px;line-height:1.45;word-wrap:normal;padding:16px;overflow:auto;background-color:rgb(247,247,247);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;word-break:normal;color:rgb(51,51,51)"><span style="color:rgb(167,29,93)">func</span> <span style="color:rgb(121,93,163)">returnsOptional</span>() <span style="color:rgb(167,29,93)">-></span> <span style="color:rgb(0,134,179)">Int</span>? {
x: <span style="color:rgb(0,134,179)">Int</span> <span style="color:rgb(167,29,93)">=</span> <span style="color:rgb(167,29,93)">...</span>
<span style="color:rgb(167,29,93)">return</span> x
}</pre><div><br></div><div><br></div><div>I would move “Proposed Solution” before “Motivation” and just call it “Proposal”. Otherwise the motivation section doesn’t make sense to read in order.</div><div><br></div><div><br></div><div>I’d add to this:</div><div>"Both of these examples represent cases where the silent behavior could potentially hide bugs or confuse readers of the code.” </div><div><br></div><div>… “, it would be better to reject the code as a type error."</div><div><br></div><div><br></div><div>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:</div><div>"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.”</div><div><br></div></div></div></blockquote><div><br></div><div>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?</div><div><br></div><div>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).</div><div><br></div><div>Mark</div><br><blockquote type="cite"><div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div><br></div><div>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:</div><div>"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."</div><div><br></div><div>Keeping the body of the proposal opinionated makes the review periods more useful because people know what is specifically being proposed.</div><div><br></div><div><br></div><div><br></div><div>"In a survey of six projects” -> Can you explicitly share the name of any of the projects?</div><div><br></div><div>Otherwise, LGTM. When you’re happy with it, please submit a PR for swift-evolution repo, I’ll review managerize it,</div><div><br></div></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">-Chris</div></div></blockquote></div><br></div></div></div><span class="">_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></span></div></blockquote></div><br></div></div><br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div></div>