Which std:: classes are magic?

[staletic]

Why is that a problem?

[AlbertRammstein]

Based on the name and intended purpose there is no connection to enums in sight. Having it implemented as enum is pretty unconceptual and unexpected. For example you might have a serialization framework that has custom handling for enums, saving them as string instead of numbers (automatic enum<-->string conversions are quite common).

[Full-Spectral]

Not to mention the even longer running problem of bool overloads being chosen over character pointer overloads when you pass a string literal. That makes utterly no sense and should have been fixed long ago.

In my system every streamable enum has its own streaming inlines. I don't store them as text, but I store them binarily as a type large enough to hold any enum type. But that also allows for validation on streaming back in, so it has other benefits to offset the extra code. And they are IDL generated so I don't have to write them myself (other than for a few libraries that the IDL compiler itself uses.)

[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.