> On Jul 11, 2016, at 6:02 PM, Jacob Bandes-Storch <[email protected]> wrote: > > On Mon, Jul 11, 2016 at 5:58 PM, Chris Lattner <[email protected] > <mailto:[email protected]>> wrote: > On Jul 11, 2016, at 4:56 PM, Jacob Bandes-Storch via swift-evolution > <[email protected] <mailto:[email protected]>> 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 > specifically?
This occurred to me when I was considering this over the weekend, but operators are already quite special. You can specify whether they are infix, prefix, or postfix, and assign a precedence. They are used without any special syntax to “apply” them, unlike normal functions which are applied with (…). I would go as far as saying that most (non-PL, non-compiler implementor) people wouldn’t consider operators and normal functions to be very closely related at all. We clearly wouldn’t want to remove the coercion for the regular functions because it’s extremely convenient. I know you’re not suggesting doing so, I’m just pointing out that if we made things uniform we’d clearly have to keep the coercion by default. > 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?)` I’m not sure it’s really worth adding another attribute just for this purpose. Mark > > - 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. > > -Chris >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
