Re: [swift-evolution] Optional comparison operators

on Tue Jul 12 2016, Chris Lattner wrote: >> On Jul 11, 2016, at 11:22 PM, Mark Lacey wrote: >> >>> >>> 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

Re: [swift-evolution] Optional comparison operators

Here's another proposal to reinstate mixed-optional versions of ==/!=/===/!==, assuming that coercion is removed: https://github.com/apple/swift-evolution/pull/426 Jacob On Tue, Jul 12, 2016 at 11:29 AM, Chris Lattner wrote: > > On Jul 12, 2016, at 10:26 AM, Jacob Bandes-Storch > wrote: > > I'

Re: [swift-evolution] Optional comparison operators

> On Jul 12, 2016, at 10:26 AM, Jacob Bandes-Storch wrote: > > I've submitted a PR for my proposal to remove these versions of />= at > https://github.com/apple/swift-evolution/pull/425 > . Thanks, LGTM, I merged and kicked it off. -Chris

Re: [swift-evolution] Optional comparison operators

> On Jul 11, 2016, at 11:22 PM, Mark Lacey wrote: > >> >> 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 a

Re: [swift-evolution] Optional comparison operators

I've submitted a PR for my proposal to remove these versions of />= at https://github.com/apple/swift-evolution/pull/425. On Tue, Jul 12, 2016 at 12:03 AM, Jacob Bandes-Storch wrote: > On Mon, Jul 11, 2016 at 9:54 PM, Chris Lattner wrote: > >> >> On Jul 11, 2016, at 9:35 PM, Mark Lacey wrote

Re: [swift-evolution] Optional comparison operators

I've thought of this before, too, and I agree that it's light enough it could probably replace implicit promotion. That said, I'm not convinced we'd really want to remove implicit promotion everywhere. I'd also be concerned that "postfix ?" is becoming too overloaded — it's already used in optiona

Re: [swift-evolution] Optional comparison operators

> On Jul 12, 2016, at 12:58 AM, Charlie Monroe > wrote: > > An example to keep in mind: > > let dict: [String : String] = ... > if dict["key"] == "value" { // String? == String > // Do something > } > > If I understand correctly, when the proposal is accepted, you'd need to do > someth

Re: [swift-evolution] Optional comparison operators

Regarding the spelling of optional promotion, I think “postfix ?” could be a solution. Notably, it already works in pattern matching (see the first two case conditions here): let anInt = 16 let anOpt = Optional(anInt) switch anOpt { case 2? : print("Deuces") case anInt? : print("Huzzah") default

Re: [swift-evolution] Optional comparison operators

> On Jul 12, 2016, at 2:58 AM, Charlie Monroe via swift-evolution > wrote: > > An example to keep in mind: > > let dict: [String : String] = ... > if dict["key"] == "value" { // String? == String > // Do something > } > > If I understand correctly, when the proposal is accepted, you'd ne

Re: [swift-evolution] Optional comparison operators

An example to keep in mind: let dict: [String : String] = ... if dict["key"] == "value" { // String? == String // Do something } If I understand correctly, when the proposal is accepted, you'd need to do something like: if let value = dict["key"], value == "value" { } -- OR -- if dict[

Re: [swift-evolution] Optional comparison operators

On Tue, Jul 12, 2016 at 2:22 AM, Mark Lacey via swift-evolution < swift-evolution@swift.org> wrote: > > On Jul 12, 2016, at 12:16 AM, Jacob Bandes-Storch > wrote: > > Okay, I guess it's fair that (T, T?) and (T?, T) overloads should have to > be a separate proposal. > > My personal motivation is

Re: [swift-evolution] Optional comparison operators

> On Jul 12, 2016, at 12:16 AM, Jacob Bandes-Storch wrote: > > Okay, I guess it's fair that (T, T?) and (T?, T) overloads should have to be > a separate proposal. > > My personal motivation is mostly anecdotal; I've found them quite useful, and > I wouldn't say they're uncommon. Sure, I mean

Re: [swift-evolution] Optional comparison operators

Okay, I guess it's fair that (T, T?) and (T?, T) overloads should have to be a separate proposal. My personal motivation is mostly anecdotal; I've found them quite useful, and I wouldn't say they're uncommon. Some use cases off the top of my head: - checking whether a dictionary contains a particu

Re: [swift-evolution] Optional comparison operators

> On Jul 11, 2016, at 11:55 PM, Jacob Bandes-Storch wrote: > > Mark, > Thanks for writing this up. Just to clarify, will these still work if your > proposal is implemented? > > let x: Int? > let y: Int > struct NotEquatable {} > let z: NotEquatable? > > x == y; x != y >

Re: [swift-evolution] Optional comparison operators

On Mon, Jul 11, 2016 at 9:54 PM, Chris Lattner wrote: > > On Jul 11, 2016, at 9:35 PM, Mark Lacey wrote: > > > On Jul 11, 2016, at 9:12 PM, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote: > > > On Jul 11, 2016, at 8:14 PM, Jacob Bandes-Storch via swift-evolution < > swift

Re: [swift-evolution] Optional comparison operators

Mark, Thanks for writing this up. Just to clarify, will these still work if your proposal is implemented? let x: Int? let y: Int struct NotEquatable {} let z: NotEquatable? x == y; x != y x == nil; x != nil z == nil; z != nil I would hope that these continue to work.

Re: [swift-evolution] Optional comparison operators

David, 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. I'm currently writing up a separate proposal to remov

Re: [swift-evolution] Optional comparison operators

There’s something I don’t understand about the proposal. How can the following code still be valid if the proposal is accepted: let x: Int! = 5 let y: Int? = 7 print(x < y) // true Isn’t there going to be a problem coercing y? David. > On 12 Jul 2016, at 08:22, Mark Lacey via swift-evolution

Re: [swift-evolution] Optional comparison operators

> On Jul 11, 2016, at 9:54 PM, Chris Lattner wrote: > >> >> On Jul 11, 2016, at 9:35 PM, Mark Lacey > > wrote: >> >> >>> On Jul 11, 2016, at 9:12 PM, Chris Lattner via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> On Jul 11, 2016, a

Re: [swift-evolution] Optional comparison operators

> On Jul 11, 2016, at 9:35 PM, Mark Lacey wrote: > > >> On Jul 11, 2016, at 9:12 PM, Chris Lattner via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >>> On Jul 11, 2016, at 8:14 PM, Jacob Bandes-Storch via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>

Re: [swift-evolution] Optional comparison operators

> On Jul 11, 2016, at 9:12 PM, Chris Lattner via swift-evolution > wrote: > > >> On Jul 11, 2016, at 8:14 PM, Jacob Bandes-Storch via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> You'd have to unwrap it, or use the ??/==/!= operators: >> https://gist.github.com/jtbande

Re: [swift-evolution] Optional comparison operators

> On Jul 11, 2016, at 8:14 PM, Jacob Bandes-Storch via swift-evolution > wrote: > > You'd have to unwrap it, or use the ??/==/!= operators: > https://gist.github.com/jtbandes/9d88cc83ceceb6c62f38 > > > I'd be okay with />= returning Boo

Re: [swift-evolution] Optional comparison operators

> On Jul 11, 2016, at 6:02 PM, Jacob Bandes-Storch wrote: > > On Mon, Jul 11, 2016 at 5:58 PM, Chris Lattner > wrote: > On Jul 11, 2016, at 4:56 PM, Jacob Bandes-Storch via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > > Personally I think we should j

Re: [swift-evolution] Optional comparison operators

You'd have to unwrap it, or use the ??/==/!= operators: 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

Re: [swift-evolution] Optional comparison operators

Correct me if I’m wrong, but wouldn’t you have to unwrap every comparison then? > On Jul 11, 2016, at 20:02, David Sweeris via swift-evolution > wrote: > > Why not have them return a `Bool?`? If both arguments are non-nil, it can > return the results of the comparison, otherwise it can return n

Re: [swift-evolution] Optional comparison operators

Why not have them return a `Bool?`? If both arguments are non-nil, it can return the results of the comparison, otherwise it can return nil. - Dave Sweeris > On Jul 7, 2016, at 16:37, Jacob Bandes-Storch via swift-evolution > wrote: > > These operators cause some potential for confusion: > >

Re: [swift-evolution] Optional comparison operators

On Mon, Jul 11, 2016 at 8:02 PM, Jacob Bandes-Storch via swift-evolution < swift-evolution@swift.org> wrote: > On Mon, Jul 11, 2016 at 5:58 PM, Chris Lattner wrote: > >> On Jul 11, 2016, at 4:56 PM, Jacob Bandes-Storch via swift-evolution < >> swift-evolution@swift.org> wrote: >> > Personally I t

Re: [swift-evolution] Optional comparison operators

On Mon, Jul 11, 2016 at 5:58 PM, Chris Lattner wrote: > On Jul 11, 2016, at 4:56 PM, Jacob Bandes-Storch via swift-evolution < > swift-evolution@swift.org> wrote: > > Personally I think we should just remove these optional-taking variants > of the comparison operators. Does anyone agree/disagree?

Re: [swift-evolution] Optional comparison operators

> On Jul 11, 2016, at 5:29 PM, Mark Lacey via swift-evolution > wrote: > > >> On Jul 11, 2016, at 4:56 PM, Jacob Bandes-Storch > > wrote: >> >> Personally I think we should just remove these optional-taking variants of >> the comparison operators. Does anyone agree

Re: [swift-evolution] Optional comparison operators

On Jul 11, 2016, at 4:56 PM, Jacob Bandes-Storch via swift-evolution 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 > remo

Re: [swift-evolution] Optional comparison operators

On Mon, Jul 11, 2016 at 5:29 PM, Mark Lacey wrote: > > On Jul 11, 2016, at 4:56 PM, Jacob Bandes-Storch > 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

Re: [swift-evolution] Optional comparison operators

On Mon, Jul 11, 2016 at 5:32 PM, Mark Lacey wrote: > > On Jul 11, 2016, at 4:59 PM, Xiaodi Wu wrote: > > Yup, I too would prefer removing the functions over removing coercion. > > > Hi Xiaodi, > > Is there a reason you think the coercion is important to keep? > > I see these as somewhat orthogon

Re: [swift-evolution] Optional comparison operators

> On Jul 11, 2016, at 4:59 PM, Xiaodi Wu wrote: > > Yup, I too would prefer removing the functions over removing coercion. Hi Xiaodi, Is there a reason you think the coercion is important to keep? I see these as somewhat orthogonal issues (allowing or disallowing coercion vs. keeping or remo

Re: [swift-evolution] Optional comparison operators

> On Jul 11, 2016, at 4:56 PM, Jacob Bandes-Storch 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

Re: [swift-evolution] Optional comparison operators

Yup, I too would prefer removing the functions over removing coercion. On Mon, Jul 11, 2016 at 18:57 Jacob Bandes-Storch via swift-evolution < swift-evolution@swift.org> wrote: > Personally I think we should just remove these optional-taking variants of > the comparison operators. Does anyone agr

Re: [swift-evolution] Optional comparison operators

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

Re: [swift-evolution] Optional comparison operators

> On Jul 11, 2016, at 4:32 PM, Jacob Bandes-Storch wrote: > > Great, thanks Mark! I look forward to it. To be clear, I’m specifically looking at making the change to remove the coercion from T to T? for operator arguments. I agree there might be other things worth looking at regarding operato

Re: [swift-evolution] Optional comparison operators

Great, thanks Mark! I look forward to it. On Mon, Jul 11, 2016 at 4:31 PM, Mark Lacey wrote: > Hi Jacob, > > On Jul 11, 2016, at 4:23 PM, Jacob Bandes-Storch via swift-evolution < > swift-evolution@swift.org> wrote: > > Bump for Swift 3. > > On Thu, Jul 7, 2016 at 2:37 PM, Jacob Bandes-Storch >

Re: [swift-evolution] Optional comparison operators

Hi Jacob, > On Jul 11, 2016, at 4:23 PM, Jacob Bandes-Storch via swift-evolution > wrote: > > Bump for Swift 3. > > On Thu, Jul 7, 2016 at 2:37 PM, Jacob Bandes-Storch > wrote: > These operators cause some potential for confusion: > > public func <(lhs: T?, rhs

Re: [swift-evolution] Optional comparison operators

Bump for Swift 3. On Thu, Jul 7, 2016 at 2:37 PM, Jacob Bandes-Storch wrote: > These operators cause some potential for confusion: > > public func <(lhs: T?, rhs: T?) -> Bool > public func >(lhs: T?, rhs: T?) -> Bool > public func <=(lhs: T?, rhs: T?) -> Bool > public func >=(lhs

[swift-evolution] Optional comparison operators

These operators cause some potential for confusion: public func <(lhs: T?, rhs: T?) -> Bool public func >(lhs: T?, rhs: T?) -> Bool public func <=(lhs: T?, rhs: T?) -> Bool public func >=(lhs: T?, rhs: T?) -> Bool 1. The meaning of T? < T? is not immediately obvious (Why is nil <