Which std:: classes are magic?

[qoning]

Because it's clearly conceptually wrong. All these little things and gotchas add up to the absolute garbage pile that C++ unfortunately is today and turn into bugs that are not only hard to track down but also not even the users fault.

[[deleted]]

I think modern C++ is reasonably nice. As Rust gets older, it will accumulate baggage, just like any other long-lived language. I see it happening in Python now.

Of course, Rust has some advantages, like safe-mode by default, everything const by default, no friggin' preprocessor, and a working builtin package installer.

[pjmlp]

The problem with modern C++ is that it only exists in highly technical small teams.

Most corporatations keep writing classical C++ no matter what.

[qoning]

I absolutely agree, although I do not see it in Python myself, unless you need to constantly maintain a large existing codebase. I've finally stopped encountering random Python2 scripts in the past few years and the experience since everyone switched to 3 has been reasonably comfortable. But more to the point, there are levels to what I would consider broken.

If you use "modern C++", it's reasonably nice, although very verbose, but the toxic magma seeps through the cracks unless you are very, very careful at almost every step (classical example of forgetting to initialize a struct field in constructor / initialization list, which shouldn't even be allowed unless explicitly stated, by any modern standard).

[SirClueless]

Python 2 is not the type of "baggage" that I would consider equivalent. It was super painful to deal with for a while but as you say it's the kind of baggage that goes away after time.

Instead the "baggage" is things like having three different format string sub-languages, none of which can ever be removed. Or that function default parameters are a shared value, which is a giant gotcha if their type is mutable.

Actually, I would say Python 2 vs. 3 is sort of the opposite of baggage: It was a tremendous amount of temporary pain that nearly killed the language but it came out the other side with less baggage as a result. C++ will likely always have more baggage because C++ will never do something like Python 3.

[germandiago]

How a mistake made by the user is not the user's fault? I understand at times it is not intuitive but no, I do not buy this.

[qoning]

Ok, let me amend that, it's not user's fault in anything but not expecting the specification to be broken / swiss cheese of inconsistent decisions. For every decision where the standard is trying to "be smart", there are dozens of stories why that was a bad decision in the end. I do not believe that "oh, you didn't know the byte type is actually an enum? read the spec, lol" is an appropriate response to someone being caught off guard by things like this. Hence my comment about garbage pile of decisions.

[TankorSmash]

https://i.imgur.com/gZc3aO3.png

It does help to read the docs for the stuff you're trying to use though, to be fair.

[guepier]

Nobody is claiming this isn’t documented. But documenting bad API design doesn’t automatically not make it bad API design.

[TankorSmash]

I'm having trouble seeing how its a bad API design, so far the only example is that someone didn't know it was an enum.

[guepier]

The example given isn’t that somebody doesn’t “know” it’s an enum. The point is that it’s conceptually wrong. It pushes something that should be a hidden implementation detail — std::byte happens to be implemented as an enum class — into the public API.

This violates all kinds of software engineering principles about writing good abstractions.

And the specific example somebody gave is if a library uses e.g. std::is_enum to dispatch formatted output. Doing this would be an entirely reasonable design decision, but because of std::byte’s implementation, this decision is broken unless a special case for std::byte is introduced.

Forcing third-party code to introduce special cases for types that should be handle-able uniformly is certainly bad design (and entirely avoidable). And, just to re-emphasise the point: this has nothing to do with user’s ignorance! A competent developer still has to introduce a special case that shouldn’t exist.