[swift-evolution] Optional comparison operators
jtbandes at gmail.com
Mon Jul 11 20:02:45 CDT 2016
On Mon, Jul 11, 2016 at 5:58 PM, Chris Lattner <clattner at apple.com> wrote:
> On Jul 11, 2016, at 4:56 PM, Jacob Bandes-Storch via swift-evolution <
> swift-evolution at swift.org> wrote:
> > Personally I think we should just remove these optional-taking variants
> of the comparison operators. Does anyone agree/disagree?
> > It does make sense to keep ==(T?, T?) and !=(T?, T?), and if coercion
> were removed, we might want to add (T, T?) and (T?, T) versions. Are there
> any other operators that would be affected by your proposal? If not,
> removing the optional </<=/>/>= would obviate the need to remove coercion.
> My opinion:
> - We need to remove T -> T? promotion from operators for a whole lot of
> reasons. People are frequently surprised by the behavior of the ??
> operator promoting the LHS to optional, for example. There are a ton of
> “bugs” that people file that are related to issues like that.
Thinking about this a bit more, couldn't the same class of "gotcha" happen
with regular functions, too? Why should this be changed for operators
Maybe it makes more sense to have some kind of "@noncoercing" parameter, so
that coercion can still take place, but operator could be defined as `func
??<T>(lhs: @noncoercing T?, rhs: T?)`
> - We don’t have conditional conformances, so Optional cannot
> conditionally conform to Equatable and Comparable in Swift 3. In a later
> release, we can consider whether adding them is a good idea.
> - We currently support equatable comparing an arbitrary optional to nil
> (one in which T is not necessarily Equatable), which I think is useful to
> keep around.
> - If we allow that, then it makes sense to allow == and != operators for
> optionals where T is Equatable, even though the optional itself cannot
> conditionally conform to Equatable. The “surprising” aspect of equatable
> comparison doing promotions will have been removed.
> The questionable piece is what to do with </<=/>/>=. I would lean towards
> removing them in Swift 3 simply because it is easier to "remove now, but
> add them back later" if they really are important. The argument for
> keeping them is that the surprising aspect will be solved by removing the
> first promotion - "42 > nil” will cease to type-check, so they may not
> actually be harmful anymore.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution