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 <swift-evolution@swift.org> 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.
On 28 Aug 2016, at 1:20 PM, Kevin Ballard via swift-evolution <swift-evolution@swift.org> wrote:
As for optional comparisons making the code cleaner, I end up using them all over the place. The case that motivated my email looked something along the lines of
if request?.httpVersion < HTTPVersion(1.0) {
// no keepalive
disconnect()
}
This particular case could be trivially replaced with
if request.map({ $0.httpVersion < HTTPVersion(1.0) }) ?? true {
On Mon, Aug 29, 2016, at 03:26 AM, Patrick Smith wrote:
Patrick
> On 28 Aug 2016, at 1:20 PM, Kevin Ballard via swift-evolution <swift-evolution@swift.org> wrote:
>
> As for optional comparisons making the code cleaner, I end up using them all over the place. The case that motivated my email looked something along the lines of
>
> if request?.httpVersion < HTTPVersion(1.0) {
> // no keepalive
> disconnect()
> }
>
> This particular case could be trivially replaced with
>
> if request.map({ $0.httpVersion < HTTPVersion(1.0) }) ?? true {
>
> but it’s uglier and harder to read.
On Aug 30, 2016, at 1:43 AM, Goffredo Marocchi via swift-evolution <swift-evolution@swift.org> wrote:
On 30 Aug 2016, at 05:00, Kevin Ballard via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Sun, Aug 28, 2016, at 01:28 PM, Dave Abrahams via swift-evolution wrote:
on Fri Aug 26 2016, Kevin Ballard <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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 emails get delivered, but it just skips some of
them, and I keep ending up missing review threads because of it.
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 can't be the only one who
uses this. I am not looking forward to copying & pasting a
reimplementation of the comparison functions into every single project
I work on.
It's very easy to write your own versions of these operators, should you
choose to keep using them. From that standpoint, I don't see why the
impact has to be huge.
You could make the same argument for a lot of stuff the stdlib provides. For example, let's remove Optional.map since it's trivial to reimplement.
I think a case for removing it may be how much Optional.map is used to work around any pains regarding using optionals.
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 missing review threads because of it.
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 can't be the only one who
uses this. I am not looking forward to copying & pasting a
reimplementation of the comparison functions into every single project
I work on.
It's very easy to write your own versions of these operators, should you
choose to keep using them. From that standpoint, I don't see why the
impact has to be huge.
You could make the same argument for a lot of stuff the stdlib provides. For example, let's remove Optional.map since it's trivial to reimplement.
I think a case for removing it may be how much Optional.map is used to work around any pains regarding using optionals.
Why? Are we masochists?
No, we want to be Swifty and do things properly with expressive syntax instead of reusing something not meant to work around the pain of using optionals ;).
(Half joking - half serious... never had any problem with sending messages to nil in Objective-C, so I may be the weird one... just think that if you already strive for clarity and expressive intent using a .map to avoid extracting the optional value is a bit hacky and unclean)
···
Sent from my iPhone
On 30 Aug 2016, at 08:14, Charles Srstka <cocoadev@charlessoft.com> wrote:
On Aug 30, 2016, at 1:43 AM, Goffredo Marocchi via swift-evolution <swift-evolution@swift.org> wrote:
On 30 Aug 2016, at 05:00, Kevin Ballard via swift-evolution <swift-evolution@swift.org> wrote:
On Sun, Aug 28, 2016, at 01:28 PM, Dave Abrahams via swift-evolution wrote:
on Fri Aug 26 2016, Kevin Ballard <swift-evolution@swift.org> wrote:
Am 30.08.2016 um 08:43 schrieb Goffredo Marocchi via swift-evolution <swift-evolution@swift.org>:
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 & paste a bunch of code into every single project. I'm already doing this with my replace(_:with:) function that you guys (Swift core team; I forget exactly who) didn't like, but that's at least simpler than the Optional comparison operators, and is only one function (and it's easier to work around the lack of this function if I don't want to reimplement it for a particular use).
Swift has a package manager, wouldn't it be possible to just implement these operators in a package/module and import it in all your projects? I didn't try it but public operators are possible aren't they? Copy&paste should not be the solution.
This could be an interesting compromise, but I'd say it shouldn't use the same operator as it's meaning differs from the norm, but in that case you'd be looking at introducing <?, >? etc. which is a lot of new operators for the task (which the Swift team I think wants to avoid).
As others have said, the proposal for a strict ordering operator ought to solve most of these issues, so it should probably be made a priority, as with it we can have strictly ordered, optional types, where the meaning of < (inferred from the strict ordering operator) is well defined, which ought to cover most types that will implement it.
Otherwise I'd say your options are either to use nil coalescing (??) or re-implement the optional forms of the operators yourself where necessary (and deal with later once strict ordering is added). I think for most cases right now this should be sufficient; disruptive admittedly, but the best option for now IMO.
···
On 28 Aug 2016, at 14:04, Tino Heth <2th@gmx.de> wrote:
Am 28.08.2016 um 05:34 schrieb Kevin Ballard via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>:
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.
As for comparing optionals, my preferred result would be an Optional<Bool>:
if (value < 5) ?? true {…
It makes no assumptions on the order, is clear and also concise.
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 am digressing sorry.
···
Sent from my iPhone
On 30 Aug 2016, at 08:44, Goffredo Marocchi <panajev@gmail.com> wrote:
Sent from my iPhone
On 30 Aug 2016, at 08:14, Charles Srstka <cocoadev@charlessoft.com> wrote:
On Aug 30, 2016, at 1:43 AM, Goffredo Marocchi via swift-evolution <swift-evolution@swift.org> wrote:
On 30 Aug 2016, at 05:00, Kevin Ballard via swift-evolution <swift-evolution@swift.org> wrote:
On Sun, Aug 28, 2016, at 01:28 PM, Dave Abrahams via swift-evolution wrote:
on Fri Aug 26 2016, Kevin Ballard <swift-evolution@swift.org> 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 emails get delivered, but it just skips some of
them, and I keep ending up missing review threads because of it.
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 can't be the only one who
uses this. I am not looking forward to copying & pasting a
reimplementation of the comparison functions into every single project
I work on.
It's very easy to write your own versions of these operators, should you
choose to keep using them. From that standpoint, I don't see why the
impact has to be huge.
You could make the same argument for a lot of stuff the stdlib provides. For example, let's remove Optional.map since it's trivial to reimplement.
I think a case for removing it may be how much Optional.map is used to work around any pains regarding using optionals.
Why? Are we masochists?
No, we want to be Swifty and do things properly with expressive syntax instead of reusing something not meant to work around the pain of using optionals ;).
(Half joking - half serious... never had any problem with sending messages to nil in Objective-C, so I may be the weird one... just think that if you already strive for clarity and expressive intent using a .map to avoid extracting the optional value is a bit hacky and unclean)