On Mon, Jul 11, 2016 at 5:29 PM, Mark Lacey <[email protected]> wrote:
> > On Jul 11, 2016, at 4:56 PM, Jacob Bandes-Storch <[email protected]> > wrote: > > Personally I think we should just remove these optional-taking variants of > the comparison operators. Does anyone agree/disagree? > > > I believe that a well-defined ordering of optionals and non-optionals is > required in order to allow sorting an array of optionals. > > You can argue about how useful this is, but it seems like it would be > important to support this for generic algorithms. > I'd be curious whether anyone can come up with a good example of why this would be useful. Optional itself isn't Comparable (the generics features required for that don't exist yet), so I don't think there's any way to use this in generic code without explicitly handling the values as being Optional, and so you might as well be required to unwrap them. > Having said that, it also seems entirely reasonable (and safer) to > disallow comparison of an optional with a non-optional value when done > explicitly in code (e.g. x < y where one is a known optional), and require > an explicit cast of the other operand to an optional in order to allow this > to compile. > Just to re-iterate my above paragraph (trying to convince myself), I think that today the operands are *always* "known optional" or "known non-optional", so there isn't really a way to distinguish between these cases.
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
