I'd really be curious about distribution of the result they see. The folklore is definitely that that there's vary high variance in how people respond to SSRIs, and not recommending them because the average value is low is pretty irresponsible.
Go get this completely wrong! It use a tuple rather than an enum for potential errors. This means you can forget to check errors and just use the invalid (nil?) return value from the function.
On the other hand, rust uses the Either enum to force you to handle the error. Alternatively you can use the ? operator to pass it to the calling function, which is reflected in the enclosing function's type.
Pet peeves nitpick: it's not even a tuple. Go doesn't have tuples. It just has special-cased "multiple return values", which means that it's often impossible to just stuff the return of a function call (error value and all) into any data structure to aggregate them. You just can't do without first defining a struct since tuples don't exist in Go.
Yep Rust approach won. Pretty much every new language is adopting Result style errors and it's been adapted to plenty of existing languages.
It's a product of functional programming, and for me I can't see how you would ever want to handle errors outside of the functional programming railway-oriented style. For me it's just superior.
Sorry Europe and Canada, $1 and $2 coins are just absolutely terrible. I never want to have to think about where my change is. Bills are much lighter than coins and stack with the rest of the bills.
When I was in Japan everything was all-cash and the smallest bill was the equivalent of a $10, with equivalents to $1 and $5 coins being in common circulation. Most wallets they sold/people had had a coin pocket to account for this.
Back when I worked at Apple no one had stickers on their laptops (gasp, who would dare!). But everyone had identical MacBook Pros, and when we had meetings, they would go in the center of the table and then everyone would have trouble telling them apart. So I got a couple of gold star stickers like you give to children for my laptop.
I try to avoid stickers from tech products which seem to be the common thing to do. Instead almost all of my stickers are from my friend's art projects.
Well, you can map over options/maybes. For-loop style iteration over an option does seem a little strange IMO, first, because syntactically it looks like overkill, and second (and more importantly), because map evals to a value, while `for` does not.
But I suppose in C++, given the centrality of looping constructs, this is what you would do to accommodate option.
You're comparing apples to oranges. In pure functional languages, Option is a fundamental type. It's a concept introduced very early on when learning FP. Historically it had the same behavior and definition.
Trying to gaslight ppl to question their reasonable reaction of std::optional transitioning from its previous behavior to an Option like behavior when no other type in C++ behaves as such is disingenuous.
Of course it is weird in the C++ context, but is it a step in the right direction? absolutely!
reply