Re: [swift-evolution] [Accepted] SE-0121: Remove Optional Comparison Operators

MfG Johannes Neubauer Von meinem iPad gesendet > Am 30.08.2016 um 08:43 schrieb Goffredo Marocchi via swift-evolution > : > > The problem is, if I have to reimplement this thing in every single project I > touch, that's a huge impact. I shouldn't have to copy &

Re: [swift-evolution] [Accepted] SE-0121: Remove Optional Comparison Operators

I may be mistaken but I am not sure map is intended to make Optionals less painful to use as you kind of imply. People that use and love optionals and say that they are not a pain to use should not point at using/abusing the map function and the potential removal of it as masochism IMHO, but I

Re: [swift-evolution] [Accepted] SE-0121: Remove Optional Comparison Operators

Sent from my iPhone > On 30 Aug 2016, at 08:14, Charles Srstka wrote: > >> On Aug 30, 2016, at 1:43 AM, Goffredo Marocchi via swift-evolution >> wrote: >> >> On 30 Aug 2016, at 05:00, Kevin Ballard via swift-evolution >>

Re: [swift-evolution] [Accepted] SE-0121: Remove Optional Comparison Operators

Sent from my iPhone > On 30 Aug 2016, at 05:00, Kevin Ballard via swift-evolution > wrote: > >> On Sun, Aug 28, 2016, at 01:28 PM, Dave Abrahams via swift-evolution wrote: >> >>> on Fri Aug 26 2016, Kevin Ballard wrote: >>> >>>

Re: [swift-evolution] [Accepted] SE-0121: Remove Optional Comparison Operators

On Sun, Aug 28, 2016, at 01:28 PM, Dave Abrahams via swift-evolution wrote: > > on Fri Aug 26 2016, Kevin Ballard wrote: > > > Goddammit. I completely missed this thread, because Pipermail > > regularly decides not to deliver the swift-evolution-announce version > >

Re: [swift-evolution] [Accepted] SE-0121: Remove Optional Comparison Operators

On Mon, Aug 29, 2016, at 03:26 AM, Patrick Smith wrote: > A little nicer I think is: > > if request?.httpVersion.map({ $0 < HTTPVersion(1.0) }) ?? true { > > It’s very explicit what the fallback is too, the original’s ambiguity makes > me uncomfortable. I find that much less readable. > BTW,

Re: [swift-evolution] [Accepted] SE-0121: Remove Optional Comparison Operators

I agree - I really don’t like these clever map constructs to work around optionals either and I avoid them at all costs. IMO they obscure intent pretty severely and shouldn’t be considered idiomatic Swift. Depending on circumstances, I might do something along these lines: guard let version =

Re: [swift-evolution] [Accepted] SE-0121: Remove Optional Comparison Operators

Whenever I see such examples I feel like map is being abused because of some of its properties rather than this. Ring the best way to deal with optionals. Sent from my iPhone > On 29 Aug 2016, at 11:26, Patrick Smith via swift-evolution > wrote: > > A little nicer

Re: [swift-evolution] [Accepted] SE-0121: Remove Optional Comparison Operators

A little nicer I think is: if request?.httpVersion.map({ $0 < HTTPVersion(1.0) }) ?? true { It’s very explicit what the fallback is too, the original’s ambiguity makes me uncomfortable. BTW, did you want to be checking for <= 1.0? With HTTP 1.0, it’s opt in.

Re: [swift-evolution] [Accepted] SE-0121: Remove Optional Comparison Operators

on Fri Aug 26 2016, Kevin Ballard wrote: > Goddammit. I completely missed this thread, because Pipermail > regularly decides not to deliver the swift-evolution-announce version > of review threads (which means they bypass my inbox). Why does it do > this? Most of the

Re: [swift-evolution] [Accepted] SE-0121: Remove Optional Comparison Operators

> On 28 Aug 2016, at 14:04, Tino Heth <2...@gmx.de> wrote: > > >> Am 28.08.2016 um 05:34 schrieb Kevin Ballard via swift-evolution >> >: >> >>> My biggest issue with Optional conforming to Comparable is that while a >>> default

Re: [swift-evolution] [Accepted] SE-0121: Remove Optional Comparison Operators

Does an empty Int sort before or after a non-empty Int? Sent from my iPhone > On Aug 27, 2016, at 22:34, Kevin Ballard via swift-evolution > wrote: > >> On Sat, Aug 27, 2016, at 07:07 AM, Javier Soto via swift-evolution wrote: >> My biggest issue with Optional

Re: [swift-evolution] [Accepted] SE-0121: Remove Optional Comparison Operators

On Sat, Aug 27, 2016, at 07:07 AM, Javier Soto via swift-evolution wrote: > My biggest issue with Optional conforming to Comparable is that while > a default implementation may sometimes be useful, it may not > necessarily be the one you want. Isn't that true for almost everything? I could use

Re: [swift-evolution] [Accepted] SE-0121: Remove Optional Comparison Operators

I find it useful because Optionals show up all over the place, and it’s very convenient to be able to compare Optional values in a straightforward fashion. Especially when you have two Optional values to compare (as opposed to comparing an Optional with a non-Optional). `nil < .some(x)`

Re: [swift-evolution] [Accepted] SE-0121: Remove Optional Comparison Operators

Here's the link: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160718/025132.html On Sat, Aug 27, 2016 at 11:21 AM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > On Aug 26, 2016, at 6:01 PM, Kevin Ballard wrote: > > This change is going

Re: [swift-evolution] [Accepted] SE-0121: Remove Optional Comparison Operators

> 27 Aug. 2016 15:58 Charlie Monroe via swift-evolution > wrote: > Now, you need to do: > > users.sorted({ > guard let firstName = $0.0.lastName else { > return true > } > > guard let secondName = $0.1.lastName else { >

Re: [swift-evolution] [Accepted] SE-0121: Remove Optional Comparison Operators

My biggest issue with Optional conforming to Comparable is that while a default implementation may sometimes be useful, it may not necessarily be the one you want. In that last example with lastName, if you wanted to change the policy for whether users without last name appear first or last, you'd

Re: [swift-evolution] [Accepted] SE-0121: Remove Optional Comparison Operators

I have personally (ab)used this for the following: class User { var email: String var firstName: String? var lastName: String? } You have a list of users based on email, so last name is optional. In Swift 2.x, you can do: users.sort({ $0.lastName < $1.lastName }) Now,

Re: [swift-evolution] [Accepted] SE-0121: Remove Optional Comparison Operators

> On 27 Aug 2016, at 02:01, Kevin Ballard via swift-evolution > wrote: > > This change is going to have a HUGE impact for me. I use this sort of > comparison _all the time_ and find it incredibly useful, and have had > literally zero bugs caused by this. Surely I

Re: [swift-evolution] [Accepted] SE-0121: Remove Optional Comparison Operators

What do you find so useful about them? And in what context does it make sense to you that `nil < .some(x)` always evaluates to true? When I found that out, I was very surprised by that behaviour (just like many others). Do you have examples of then an optional comparison makes the code clearer?

Re: [swift-evolution] [Accepted] SE-0121: Remove Optional Comparison Operators

Goddammit. I completely missed this thread, because Pipermail regularly decides not to deliver the swift-evolution-announce version of review threads (which means they bypass my inbox). Why does it do this? Most of the emails get delivered, but it just skips some of them, and I keep ending up

Re: [swift-evolution] [Accepted] SE-0121: Remove Optional Comparison Operators

Great! I have an attempted implementation here. Would appreciate if someone can kick off a CI build/test. https://github.com/apple/swift/pull/3637 On Wed, Jul 20, 2016 at 5:38 PM Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > Proposal Link: >

[swift-evolution] [Accepted] SE-0121: Remove Optional Comparison Operators

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0121-remove-optional-comparison-operators.md The review of "SE-0121: Remove Optional Comparison Operators" ran from Active review July 12...19. The proposal has been *accepted*. Feedback has been universally positive