I agree, I was stuck on boost::optional for a long time for this reason, and I only use boost::variant2 for my variant needs, although code can still build with std:: in case a customer really does not want boost

[s/asilo/asio/; Autocorrect has been wrecking havoc to all my comments today]

A lot of those design decisions in OSes were influenced by hardware limitations of home computers in the 1970s and 1980s. UNIX may have been around since '71, but Windows NT was designed to expose an API similar to DOS-based Windows 95 (the Win32 API), which in turn was designed around backward compatibility with MS-DOS, which in turn was designed to mimic other other "DOS" OSes from other companies in the late 70s. This ultimately traces back to a time when consumer-grade hardware just couldn't handle all the features we now take for granted, like virtual memory and preemptive multitasking, or even floating point math.

However, Windows NT was also written after machines capable of running Unix cost less than a BMW so a lot of the good folks in Redmond during the early 90s took some liberties to improve on some fundamental design flaws of UNIX.

1. "Everything is a file" is very flexible for writing server applications where the user is expected to know and trust every program, but it is potentially harmful to expose devices as files to non-technical users. Nowadays with UEFI, you can even pipe /dev/zero to /dev/mem or /dev/port and brick your motherboard. There was a patch for this, but there are old servers running old Linux versions in the wild that can be permanently bricked.

2. Arguably, exposing such a wide range of signals to a userland program for it to handle is a design flaw, like the memory fault signals SIGSEGV and SIGBUS. They were not designed for IPC or exception handling, but they ended up being used that way by a lot of developers over the years. I won't start a war to make the case because I can see both sides on that, but #3 below is not controversial at all.

3. NTFS ACLs are a big improvement over UNIX-style ugo-rwx permissions. FWIW, they're also easier to work with than POSIX ACLs.

Just something to think about: the Windows way is radically different because compatibility with ye-olde DOS running on 68k CPUs ruined it in some ways, but in other ways its design was driven by learning from UNIX's mistakes.

despite the confusing name, Win32 is not just a 32-bit libc, it's a 64-bit libc on 64-bit Windows.

I will boldly state that std::variant makes all code worse and it is always better to not use it.

I love sum types in Rust. They’re great. This stuff exists solely to add ergonomics. If it’s not ergonomic it’s just making your code worse!

std::variant is fundamentally broken because it uses types as its discriminant. Want a variant with two ints that represent two things? Fuck you, you can’t. Rust enums of course can do this.

std::visit is an abomination. As is the template overloaded bullshit you have to copy paste into projects.

And of course the error messages when you get when it’s wrong are atrocious even by C++ standards.

No. std::variant is awful and you should simply never use it. This could change in 2040 when you can use C++32. But for now just avoid it.

> Kill me, but I never saw the point over abstract base classes and polymorphic behavior defined in the subclasses.

They're different tools which can fit different situations better or worse. std::variant fits some situations better (e.g., expressing a known closed set of types which may or may not share a common interface - tree nodes, option/result types, state machines, etc.), while interfaces/virtual functions fit some other situations better (e.g., expressing a potentially-open set of types with a shared interface - widget hierarchies, type erasure, etc.).

> Now purists will scream “compile time optimization!”

I actually feel like under most circumstances it's how closely one option or the other matches your problem domain that influences the decision one way or the other, not performance.

In any case, it doesn't really help that std::variant is somewhat neutered in C++ by a rather awkward interface as well as the lack of generalized/ergonomic pattern matching such as that offered by Haskell/ML-likes/Rust.

It doesn't have proper pattern matching (you have to use a visitor class or the weird overload trick), and it sucks for compile times. It should have been a language construct rather than adding it to std, but the committee is often too scared to touch the language because they are stubbornly unwilling to break backwards compatibility.

C++ is a proud New Jersey language. So the priority has been and continues to be ease of implementation. If it's tricky to make it work right, don't sweat it - the users (in this case that's us programmers) will put up with it not working right.

std::variant has valueless_by_exception - the C++ language wasn't able to ensure that your variant of a Dog or a Cat is always, in fact, a Dog or a Cat, in some cases it's neither so... here's valueless_by_exception instead, sorry.

That makes sense! What's funny is, I went to go write the equivalent Rust code:

    struct Logger;
    
    impl Logger {
        fn log(&self, _: &str) {}
    }
    
    fn do_something(data: &str, logger: Option<Logger>) {
        for l in logger {
            l.log(data)
        }
    }
    
    fn main() {
        let logger = Some(Logger);
        let data = "foo";
        
        do_something(data, logger);
    }

    warning: for loop over an `Option`. This is more readably written as an `if let` statement
     --> src/main.rs:8:14
      |
    8 |     for l in logger {
      |              ^^^^^^
      |
      = note: `#[warn(for_loops_over_fallibles)]` on by default
    help: to check pattern in a loop use `while let`
      |
    8 -     for l in logger {
    8 +     while let Some(l) = logger {
      |
    help: consider using `if let` to clear intent
      |
    8 -     for l in logger {
    8 +     if let Some(l) = logger {
      |

I think this is most useful in generic contexts, I agree that I would not write this exact code this way because it does feel weird, if you know you have an Option, if let is the way to go. But if you're writing code over generic iterators, it can be nice that it exists.

All true but consider writing templates/generic code, where "logger" might be a std::optional or a std::list/vector/whatever. Same syntax, different types. Pre-C++26 you'd need a specialization for std::optional, now you don't.

Oh! so it is. Ta.

Note that despite this work in C++ you can't flip the script to if ("hello".contains(username)) unlike Rust

Rust will also let you: "FOO".contains(char::is_uppercase)

That's showing off three clever tricks Rust has that C++ does not, but one day it will just be compile time evaluated as true and that's one place C++ is richer today. Many other things in Rust can be but Rust's traits aren't today allowed to be compile time evaluated, so the fact that we could determine at compile time whether there's an uppercase letter in FOO isn't enough yet. One day.

That was tongue-in-cheek. Some people really are that enthusiastic about every minor C++ feature. Just watch certain cppcon talks.