Hacker News Reader

Comment by codeflo | Hacker News Reader

Many are of the listed items are merely being deprecated. These shouldn’t really qualify as breaking changes. In fact, the ability to migrate away incrementally is precisely the point of deprecating instead of removing a feature.

What surprises me is that a lot of the deprecated functionality seems really recent — C++14 or newer. Compatibility is C++’s big thing, that’s historically why it kept almost all of C as a sublanguage. I know organizations where migrating to C++11 is still an ongoing process. It’s not great news if features become obsolete faster than many users can adopt them.

View on HN

Mostly deprecations mean something was deemed to be a bad idea, which means it's at the very least worth taking a moment to evaluate whether somehow they were a good idea when you did them.

For example should I have a method whose parameters are volatile? Well, why did I do that? It didn't do anything in C++ 17 and it still doesn't do anything in C++ 20 but now it's deprecated. Programs are written first and foremost to be read by other humans, but what was I trying to communicate by writing "volatile" on a parameter ?

The deprecation of composite operators on volatiles is an even better example. Those do something, but what they do might surprise programmers. Rewriting and then reading the rewritten example is an opportunity to discover that your code was broken anyway because now it's obvious. This obviousness is why deprecating the composites happened (and why it's sad that C++ 23 un-deprecates some of them).

> Programs are written first and foremost to be read by other humans

extremely bold assumption. plenty of write-only or use-once code in the wild.

Fair, lets modify that to just "humans" not "other humans" and say instead that programs should be written first and foremost with this in mind.

I have never discovered a reliable way to discern whether I will re-use some code. Of course I could just delete it after first use and declare it "use-once" that way, but that's cheating, if I just have to type in the same program tomorrow we should admit that deleting it and rewriting it was a pessimisation.

In the specific case of volatile parameters I can't figure out whether writing this in use-once code is more stupid or less stupid. On the one hand, you aren't misleading anybody else because the compiler knows perfectly well this doesn't do anything, on the other hand with the only human participant being yourself maybe you think it does something and whatever that is you're wrong so that's very bad.

Other humans is fine if you include "yourself, in the future" as an "other human" in the ship of Theseus sense

I think if write-only code were the norm, then APL would be more popular.

But there are APL, k, j and other array lang programs. You can't do as if those don't exist when talking about programming as a whole. Perl used to be pretty popular too.

I didn't say array programming doesn't exist, I said it's not popular. How many people actually use those languages compared to e.g. Python, where readability is one of its main features.

> Perl used to be pretty popular too

And now it’s a meme due to how illegible it is.

I’ll put it this way, there’s a reason Brainfuck is a joke lang instead of something people seriously use.

Also, reading and writing are not orthogonal skills. One has to read to be able to write. I read my programs constantly as I'm writing them.

and I am not writing about popularity, just saying that there are many in an absolute sense (which is honestly the only thing that matters in practice, relying on popularity of things relative to each other in a state of abundance is absolutely stupid)

Then I don’t understand your point. The initial claim was that programs are written for human consumption first and foremost. To me, you seem to be replying that programming languages exist that are write only. In that case, agreed. But I don’t see how that is meant to counter the claim that programs are written for humans.

I disagree with the "first and foremost" part - more precisely, I don't think it makes any sense to speak about this. There are people whose entire career will be only APL-ish or whatever funky ML-derived dialect, writing programs in a team of 1 and basically converting their thought processes directly into code, and their experience matters exactly as much as the experience of the X million developers in easier / more team/read-oriented languages matters.

K is very niche, but in its niche is a extremely popular.

> Mostly deprecations mean something was deemed to be a bad idea

"Most" maybe by count, but I'm not sure if it's "most" by usage frequency. There have been & will be lots of nonsensical deprecations that are much more common in existing code than "putting volatile on an object argument" (which I've honestly never even seen anyone do in my life)... like static (which was undeprecated, thankfully, but how were people supposed to know this ahead of time?), std::aligned_storage, std::bind1st, std::iterator. They're frustrating as heck, have questionable merits to begin with, and working around the deprecations in existing code provides practically zero business value.

So as I understand this, you don't agree that std::iterator was deemed to be a bad idea?

I mean, I personally would feel comfortable defending the idea that is a bad idea, but that's not even what I'm saying, I'm only saying it was deemed to be a bad idea, which is exactly what the proposal for deprecating it explains.

No, all I'm saying is that, as I see it, (a) it wasn't causing enough harm (if any at all) to warrant deprecation, and (b) that removing it doesn't deliver any worthwhile benefit either.

The volatile parameters deprecation is one of the stranger decisions, though, since there are plenty of constructions that don’t do anything but are still allowed by the language. I see this as a matter of style that might be useful to warn about, but shouldn’t be policed as an error by the compiler.

Deprecated features are compiler warnings, not compiler errors, unless you use -Werror or the like.

FWIW it participates in overloading. Did you ever try to overload all combinations of teplate specializations? With volatile is even worse.

The real solution, which decades from now will be the eventual common-place, but no one dares to imaging the possibility today is that when languages deprecate a feature, the compilers deliver code-mods that migrate your code-base perfectly.

But people are afraid of going that route because of the bad press around Python 2 / 3. We need a new generation of developers that don't remember that.

Today, there's already static-code analysis tools that automatically migrate entire code-bases to use new language constructs. The technology is there. It's the people who lack imagination to make it happen.

Once it becomes commonplace, a large % of developers will care very little if some obscure feature of C is dropped. They'll just enjoy having a more streamlined language with all the legacy crap gone.

Transformations are difficult.

Rust provides best effort transformation for its Editions (which only touch syntax) in cargo fix --edition, but even that's only best effort. If a proc macro does something ludicrous (see Mara's whichever-compiles! macro for example) how can the transformation hope to keep up?

C++ versions are in much deeper, they not only change the language syntax, but also semantics of existing features. Sometimes the intended effect is null (but intentions may not match reality) and sometimes it is not.

C++ also substantially changes the standard library. Rust's standard library grows but doesn't get redefined in new Editions, so if you call a deprecated Rust function it's not going anywhere, whereas a deprecated C++ method might actually go away in a future version.

It's a shame that the best effort tools aren't provided with C++ compilers, but even if they were provided on a large codebase it's only the beginning for large projects.

clang-tidy is such a tool, provided with a C++ compiler - although incomplete

UB throws a huge wrench into all of this. The behavior of a C++ program is defined by a combination of the code, the compiler, the compiler flags, and the target archecture. You can't write a source to source translator that preserves the semantics of a program with UB without that extra information about how it was compiled. It's a very hairy problem.

Doesn't Google Abseil, the standard library replacement, do this?

https://abseil.io/

It is not a replacement, it is a staging ground and annex.

Swift is another one that has had a really bad migration between major versions, I can’t really remember now but it was either 2->3 or 3->4. They had a static migrator and it barely helped, it would get into loops where it would e.g. flip flop between two different uncompileable fixups.

Seems like this is a really hard problem, what is an example of a platform that has solved it perfectly or is even close? Swift was a brand new language, it should be easiest to do it there vs any system with legacy (although it was designed to interoperate with ObjC, so… maybe legacy remains).

It was 2-3. My take at the time was that they built an add-on to crash xcode.

It's a branding problem. They should probably be viewed as different flavors. Using say herbs or colors instead of numbers would help.

If every time they're going to add things, remove things and break things then we're in practice talking different strands.

Imagine some preprocessor where you can mix them like

#flavor(ginger)

Instead of say c++11 and then proceed with whatever flavor as necessary.

I know you can do that at the linker and with makefiles and compile flags, this is about a more sane presentation.

> It's a branding problem. They should probably be viewed as different flavors.

They are already different language versions. They're specified in entirely different standards. I don't see what's left to be confused about. At most, perhaps the C++ standard committee could be criticized for repeatedly going out of their way to maximize backward compatibility.

> If every time they're going to add things, remove things and break things then we're in practice talking different strands.

They are already different standard. What's there to miss?

> I know you can do that at the linker and with makefiles and compile flags, this is about a more sane presentation.

This take doesn't make sense. The C++ version being used in a project is a property of the project, not of the translation unit or individual files. A project is comprised of multiple declarations and corresponding definitions, which are spread around and reused and make sense as a whole. It would not make sense to, say, have a translation unit comprised of X C++11 definitions mixed with Y C++20 definitions.

There's a lot there.

Let's get the technical part done first.

Historically after you create object files the linker doesn't care what c++ standard the source was. So you could carefully combine different standards. I guess I have to establish I'm talking about the GNU toolchain here and that it's been a few years since I've done this. I'll try it again when I get home, maybe that all blows up now.

Now about the other parts. I totally agree with you. However we're dealing with humans and if they see incrementing numbers then the word "upgrade" and "deprecated" and "unsupported", maybe even "inefficient" gets bandied about just because we're using numbers.

We have to go back to the core lesson of Perl 6, it shouldn't have been called Perl 6 because it suggests a hierarchical comparison and relationship that isn't an accurate depiction of reality.

I wish everyone was sincere and competent but there's a natural tenancy to act based on the context that a structure affords.

Churchill stated it as "we shape our buildings and afterwards our buildings shape us".

So if the standards are better understood as siblings of each other then we need to brand them accordingly and not through a structure that suggests hierarchy, quantity of features, and degrees of relevance.

Thanks for your response. I enjoyed reading it

> Historically after you create object files the linker doesn't care what c++ standard the source was.

Mechanically this is true, but just because we can link object files together doesn't mean the resulting program makes sense.

Suppose I have an object file I made with GCC's copy-on-write C++ 98 strings and then I linked that to an object file I made with GCC's modern C++ 11 short string optimised strings. If these objects think they're talking about the same string then the resulting executable is nonsense and will probably crash or misbehave badly.

It might be helpful to think of WG21's attitude to compatibility as occupying a sort of "strategic ambiguity" akin to the US stance on Taiwan. For example when it comes to ABI changes, the committee voted that they shouldn't happen... yet. Not that they will happen within some horizon, but nor that they won't happen.

Maybe you have a deeper understanding of the GNU GCC toolchain than I do but I'm able to link together languages with far more dramatic divergences than that.

For instance, Go and C : https://go.dev/doc/install/gccgo (it's pretty far down, let me quote: "The name of Go functions accessed from C is subject to change. At present the name of a Go function that does not have a receiver is prefix.package.Functionname. The prefix is set by the -fgo-prefix option used when the package is compiled; if the option is not used, the default is go. To call the function from C you must set the name using a GCC extension.")

I just had a small C program call a fmt.Println from a go library at my console to confirm. extern the declaration in C to match the calling convention of go, compile them to objects, then ld with the appropriate libs.

Of course you can break the friendship they can have, this is programming, that's easy to do.

This can be demonstrated with different C++ versions as well. The C/Go example was meant to show how extremely different languages can interact when you're careful enough in your build process.

When gcc broke the string ABI they made sure that code that uses one version wouldn't link with code that uses the other one.

Only for the most common case. Try e.g.

  struct muhahaha {
    std::string member;
  };

library.cpp98:

  oops(muhahaha param);

program.cpp20:

  int main() {
    oops({"this will link just fine and there will be nothing warning you about your fate"});
  }

Not only it is possible, it is routinely done. At $WORK we have libraries that are use std=20 features in its implementation and only expose a c++=14 interface because that's what expected by our clients.

It is mildly painful, bit not more painful than restricting to c++14.

> At $WORK we have libraries that are use std=20 features (...)

That's specified at the package/project level. You're inadvertently proving my point.

> (...) and only expose a c++=14 interface because that's what expected by our clients.

That's also configured at the package level, because the interface headers need to be included in translation units from projecta configured tu be C++14.

Again, you're also inadvertently supporting the point I made.

Chromium compiles with -Werror, so deprecation warnings must be fixed before we can upgrade.

Reply on news.ycombinator.com