Sorry folks :(. But std::optional works as one expects - you can write functions to accept std::optional and you just check early on if it evaluates to true and just return empty as needed, so you can chain functions neatly.
Hmm as a full-time Haskeller “don’t use pattern matching” is news to me. Do you mean “don’t use pattern matching for fundamental vocabulary types like Maybe or Either? In which case it’s a reasonable guideline. For types representing your business domain, pattern matching is perfectly good practice. IMHO exhaustiveness checking of pattern matching is an indispensable feature for modelling your domain with types.
I guess it’s not much use after-the-fact, but I believe we have reasonable solutions for these issues nowadays:
Docker, and the official GCC image. If clang is a hard requirement, it should be fairly easy to find an image based on a distribution with a fairly recent version of LLVM in its repositories and quickly build on top of it.
Hey, I should check out Nix. I keep hearing about it. Thanks!
The docker solution I’m pretty skeptical about. First, this would require me to run my application inside docker (right?) Secondly, docker for mac keeps eating up disk space. It’s SO annoying and last time I checked it was a won’t fix. I #deletedocker from my mac.
If you build your binary through Docker, you either have to run it in a container, or you can link it statically, assuming you run Linux on your host OS. I understand how both options aren’t very appealing to you.
Nix is a really useful collection of software. I have no first hand experience with it on OS X, but anecdotally, it works fine. Do check it out!
At one extreme, Arch Linux and Debian Unstable, where you can do just about anything but there’s only about 98% chance it’ll work on a given day.
At the other extreme, CentOS/Red Hat Enterprise Linux, where there’s a specific set of things that are guaranteed 100% reliable, and pretty much everything else will break.
In between are macOS and Windows, where most things work and keep working, but sometimes you reach for that one extra thing and wind up having to upgrade your OS. It’s a pain, but consider it an amortized cost over not spending five minutes a day tracing through shell scripts to find out where a particular thing is failing.
To be fair, I haven’t had unstable break on me for years. But I do tend to mostly track testing rather than unstable & keep a close eye on what apt wants to upgrade.
I agree, I’ve had a pretty good experience with Debian unstable in the past 10 years or so (prior to that it used to break more). Contrary to the name, it isn’t really the anything-goes staging area (at least not anymore). To upload to unstable, a package is supposed to have been at least minimally tested, should build cleanly from source, should install cleanly without dependency issues, etc. There is a more anything-goes staging area for packages still working out the bugs, experimental. But you wouldn’t run it as a distribution, only pull in specific packages from there to test.
MacOS itself does not break on every update* but homebrew packages break very often. After each update half of them stop working due to some library having wrong version or for some other reason. Packages often fail to install or install in broken state. Sometimes newer versions of packages has features disabled by default or entirely (i.e. GUI dropped). I know homebrew is mostly hobby project but I had no such bad experience in Gentoo or Arch. And without homebrew, Mac OS is just a glamorous runtime for Photoshop.
`* Except starting from 10.13, update from 10.12 failed for me, leaving system in non-booting state, then after fixing that, each minor update started to install twice, now it even offers me to install ancient security update from January. This is literally Mac OS Vista.
Did you add build flags that prevented brew from using the default binary distribution? Why? When the build was taking forever you didn’t think that maybe your extra flag wasn’t important to test std::optional? Nome of the build options to that package are remotely necessary for most people.
As for installing Xcode, why was your OS so out of date? Xcode has only required High Sierra for a month. You’ve had 7 months to install High Sierra. Sounds like your problem.
What is OP’s problem? Having to turn on the computer? Where’s the line? At some level, we need to take responsibility for being prepared to do what we plan to do. std::optional isn’t supported by my dos box with turbo pascal either.
Hopefully we can both agree that “DOS box with turbo pascal” and “last year’s version of a current system” are different situations, only one of which has any connection to the discussion at hand.
This is like the inverse of the for want of a nail parable. All you wanted was to shoe the horse to send a message, but you needed to make a nail, so you needed to mine some ore, so you needed to feed the workers, so you needed to grow some wheat, so you needed to plow the field. So much yak shaving!
All I wanted was to try out this new nail for the shoe. I went to the nail man, and he said, but this nail needs a new hammer. See Joe. I went to Joe and Joe said, but this hammer needs a new tool shed. See Moe. I went to Moe and Moe said, but this tool shed needs a new house. So I took out another mortgage. And so it goes.
People immediately think of std::optional as a great thing to return, but it isn’t. You lose the failure reason! Use a result type (a la rust) for that.
I thought it would actually be about
std::optional, not workspace issues that have nothing to do with the problem at hand.TL;DR: keep your toolchain up to date if you want to use recent language features.
yeah. I suspect better article naming would be better at not leaving people feel like they kept on expecting the article to go somewhere it didn’t.
I think it’s funny because the reader’s experience parallels the author’s experience of wanting to get someplace.
Somebody gets me! :)
Sorry folks :(. But std::optional works as one expects - you can write functions to accept std::optional and you just check early on if it evaluates to true and just return empty as needed, so you can chain functions neatly.
Now, if only we could have pattern matching …
I think the consensus of languages with options and pattern matching is “don’t use pattern matching, use combinators”.
Hmm as a full-time Haskeller “don’t use pattern matching” is news to me. Do you mean “don’t use pattern matching for fundamental vocabulary types like
MaybeorEither? In which case it’s a reasonable guideline. For types representing your business domain, pattern matching is perfectly good practice. IMHO exhaustiveness checking of pattern matching is an indispensable feature for modelling your domain with types.Yes.
Consensus, really? I’m a big fan of combinators, but I’ll still match on option types sometimes if I think it looks clearer.
Ooh, this is interesting to me - can you expand on this (or point me to some writeups)? Thanks!
Agreed. I read all the way down and nothing significant about std::optional.
I thought it was going to be some sort of piece about how using std::optional could lead to yak shaving or something :(
I guess it’s not much use after-the-fact, but I believe we have reasonable solutions for these issues nowadays:
Nix has particularly helped me keep my dev dependencies out of my base system, and is a nifty tool to have under your belt.
Hey, I should check out Nix. I keep hearing about it. Thanks!
The docker solution I’m pretty skeptical about. First, this would require me to run my application inside docker (right?) Secondly, docker for mac keeps eating up disk space. It’s SO annoying and last time I checked it was a won’t fix. I #deletedocker from my mac.
If you build your binary through Docker, you either have to run it in a container, or you can link it statically, assuming you run Linux on your host OS. I understand how both options aren’t very appealing to you.
Nix is a really useful collection of software. I have no first hand experience with it on OS X, but anecdotally, it works fine. Do check it out!
At one extreme, Arch Linux and Debian Unstable, where you can do just about anything but there’s only about 98% chance it’ll work on a given day.
At the other extreme, CentOS/Red Hat Enterprise Linux, where there’s a specific set of things that are guaranteed 100% reliable, and pretty much everything else will break.
In between are macOS and Windows, where most things work and keep working, but sometimes you reach for that one extra thing and wind up having to upgrade your OS. It’s a pain, but consider it an amortized cost over not spending five minutes a day tracing through shell scripts to find out where a particular thing is failing.
To be fair, I haven’t had unstable break on me for years. But I do tend to mostly track testing rather than unstable & keep a close eye on what apt wants to upgrade.
I agree, I’ve had a pretty good experience with Debian unstable in the past 10 years or so (prior to that it used to break more). Contrary to the name, it isn’t really the anything-goes staging area (at least not anymore). To upload to unstable, a package is supposed to have been at least minimally tested, should build cleanly from source, should install cleanly without dependency issues, etc. There is a more anything-goes staging area for packages still working out the bugs,
experimental. But you wouldn’t run it as a distribution, only pull in specific packages from there to test.MacOS itself does not break on every update* but homebrew packages break very often. After each update half of them stop working due to some library having wrong version or for some other reason. Packages often fail to install or install in broken state. Sometimes newer versions of packages has features disabled by default or entirely (i.e. GUI dropped). I know homebrew is mostly hobby project but I had no such bad experience in Gentoo or Arch. And without homebrew, Mac OS is just a glamorous runtime for Photoshop.
`* Except starting from 10.13, update from 10.12 failed for me, leaving system in non-booting state, then after fixing that, each minor update started to install twice, now it even offers me to install ancient security update from January. This is literally Mac OS Vista.
In Homebrew the llvm package is bottled for Sierra. Bottles are binary packages. It should have been a simple download and untar, handled by brew, unless you broke something.
Did you add build flags that prevented brew from using the default binary distribution? Why? When the build was taking forever you didn’t think that maybe your extra flag wasn’t important to test std::optional? Nome of the build options to that package are remotely necessary for most people.
As for installing Xcode, why was your OS so out of date? Xcode has only required High Sierra for a month. You’ve had 7 months to install High Sierra. Sounds like your problem.
“You have not done the busywork Apple expects of you” should not be the OP’s problem.
What is OP’s problem? Having to turn on the computer? Where’s the line? At some level, we need to take responsibility for being prepared to do what we plan to do. std::optional isn’t supported by my dos box with turbo pascal either.
Hopefully we can both agree that “DOS box with turbo pascal” and “last year’s version of a current system” are different situations, only one of which has any connection to the discussion at hand.
Is it last year’s version or is it current?
This is like the inverse of the for want of a nail parable. All you wanted was to shoe the horse to send a message, but you needed to make a nail, so you needed to mine some ore, so you needed to feed the workers, so you needed to grow some wheat, so you needed to plow the field. So much yak shaving!
A slight alteration to you tale @tedu:
All I wanted was to try out this new nail for the shoe. I went to the nail man, and he said, but this nail needs a new hammer. See Joe. I went to Joe and Joe said, but this hammer needs a new tool shed. See Moe. I went to Moe and Moe said, but this tool shed needs a new house. So I took out another mortgage. And so it goes.
“my dos box with turbo pascal”
Oh yeah, that reminded me I had a submission about that. ;)
People immediately think of std::optional as a great thing to return, but it isn’t. You lose the failure reason! Use a result type (a la rust) for that.