I've used it a while ago, but got burned by very uneven support across compilers — MSVC required special tweaks, and old GCC would create crashy code without warning.
It was okay for basic embarrassingly parallel for loops. I ended up not using any more advanced features, because apart from even worse compiler support, non-trivial multi-threading in C without any safeguards is just too easy to mess up.
Swift was designed as C, Objective-C and C++ replacement from the start, and those statement have not yet been removed from its official documentation.
Naturally they couldn't tackle everything at once.
If that was the plan from the start I'd expect them to be more careful about dependences on reference counting and implicit allocations. It's more optimized than ObjC, but still has things like loops that iterate over a logical copy.
I take their old statements about replacing C and C++ as the same aspiration that Golang had to be a systems programming language.
This quirk needs to be in a tutorial or a developer-oriented reference. Involving an ISO committee in this wouldn't produce a document that makes it any easier to understand it.
This is because from the language perspective, there's no such feature. It's just a surprising combination a wildcard pattern that doesn't bind, and a drop scope of temporaries created in expressions. Each of these features is independent of the other, and are documented separately.
The Ferrocene specification and the Rust reference are almost identical in this regard:
These features should be described more precisely, but because `let _ = temp` is not a special case, but a regular case of `let PATTERN = EXPR`, a formal spec wouldn't redundantly document that combination.
Understanding Drop order doesn't need a spec, but needs all of the relevant bits of the specification extracted and described in one place. For example, the spec is pretty clear that `if let` is translated to an equivalent `match` statement, which is sufficient to implement it. What it doesn't spell out for the readers, is that scope of temporaries in `match` covers the entire match statement, and this happens to include `_ => {}` fallback pattern for the `else` in `if let`, so temporaries from the condition are still alive in the else block. This is a surprising quirk, but the surprise doesn't come from lack of specification, just lack of end-user-friendliness of the spec format, and you shouldn't expect a formal spec to be a tutorial.
The pre-rendered backgrounds were breathtaking in the 90s, but today the old off-line ray tracing looks worse than what modern games can render (same goes for the original Myst).
The remastered version has been released before AI upscaling got interesting. I wonder if a re-remastered version could be made look better.
If you don't know the language, and it's different from what you know, it may look incomprehensible to you whether it's complex or not.
For example, the Korean alphabet is pretty simple, and the spelling is simpler than English, but to English speakers it can look intimidating, like hundreds of blocks of unrecognizable squiggles.
The article (over)uses macros, which make the code look more convoluted than it really is. The macro-by-example syntax is conceptually simple, but it has a punctuation-heavy syntax that may look alien if you don't know what you're looking at. BTW, this macro system has been originally designed for JavaScript, which is why even in Rust it looks odd by Rust's standards.
I think I know the author of the bug :)
But I use a C dialect that has bounds-checking.
Abstractions leak anyway (see Meltdown/Spectre).
https://meltdownattack.com/
It's not about blame. It's about recognizing the need for safe infrastructure: physically separated bike paths, not painted gutters. Physics does care about the difference between crossing a painted line vs hitting a bollard.
Dedicated bike lanes almost always share the same risks as the incident in the OP: the intersections are still shared. And sometimes driver behavior is even worse when dedicated bike lanes exist at intersections, because drivers turning right forget they are sharing the intersection with bikes proceeding straight-through from a lane on their right.
When "social" was a hot new thing, Google suddenly wanted to be Facebook, and started making all of their products part of Google+, whether it made sense or not.
Google+ required having a public profile with a real name. Gmail/calendar/docs users who were tricked into activating plus, but didn't comply, got banned or forced to make a real name profile. Merging of Hangouts, Orkut, Blogger, YouTube comments, and Play Store reviews into the same "social network" made no sense. It was a blatant move to inflate user numbers, at cost of annoying users of the other services, who didn't sign up for a me-too Facebook. That was the first time when Google became uncool.
It was okay for basic embarrassingly parallel for loops. I ended up not using any more advanced features, because apart from even worse compiler support, non-trivial multi-threading in C without any safeguards is just too easy to mess up.