GCC Developers Discuss Possible -std=c++current & -std=c++future Options

[phoronix]

Phoronix: GCC Developers Discuss Possible -std=c++current & -std=c++future Options

Inspired by Microsoft's compiler toolchain having a "std:c++latest" option for automatically targeting the latest supported C++ spec, GCC compiler developers have been discussing the possibility of a similar feature with the ability to specify -std=c++current for the current C++ standard or -std=c++future for the future/draft specification...

https://www.phoronix.com/news/GCC-std-CPP-Current-Future

[carewolf]

Then you just need a c++complete for the last standard that has been fully implemented also in the standard library. Which would be ~c++17 currently.

[marios]

it will be fun when people start using it at makefiles...

[baka0815]

What we would really need is -std=c++what_the_author_really_meant (aka Mind Reading Interface).

[kpedersen]

What we would really need is -std=c++what_the_author_really_meant (aka Mind Reading Interface).

std=*

"I don't care what standard (or even what language), just make it compile and run!"

Kind of similar to specifying:

cmake_minimum_required(VERSION ${CMAKE_VERSION})

Typically would just put 2.6 for lowest common denominator of features. Yet it started complaining a year or so that 2.6 was too old. So what good is it? Just do the thing!

[Mahboi]

Ridiculous. std=C++with_chocolate_chips or nothing. This language will not be feature complete without this.

[skeevy420]

I'm surprised that "previous" wasn't also suggested for the day that "future" becomes "current" and shit hits the fan. That just seems like a common sense option. Perhaps even a "legacy" that allows using the oldest standard version the compiler officially supports (I'm assuming things like 98 and 03 become depreciated over time).

[skeevy420]

Then you just need a c++complete for the last standard that has been fully implemented also in the standard library. Which would be ~c++17 currently.

In the discussion "stable" was suggested.

[F.Ultra]

I don't understand the use case at all. If your c++ code needs a certain minimum of language features but you are afraid that it might break with a future version then why not specify exactly the minimum that you want? std=current/next/prev will be a constant moving target, will mean different things depending on which version of the compiler you happen to have on the system.

[Ironmask]

Wow, this is the worst idea I've heard all day. Run your package manager's update script and break your source code! Share the same repo with your friends and get a different output!
I genuinely can't think of a single use for this, except maybe to make tutorials for newbies easier. But then they're not even going to be doing much that concerns specific compiler versions. It's not even a useless feature, it's an anti-feature, like C++ exceptions. Something people are going to have to work around and cleanup after and police the community so nobody abuses it.

F.Ultra has a good idea. That's how Rust dependencies work too, you can define a range of versions and the toolchain will just pick whichever one works. Although when it comes to languages, one downside to that idea is that you'd have to ensure your code doesn't subtly break over a range of compiler versions, instead of just the one you're targeting. Really the best option is to target a compiler and stick with it, code that compiles with other compiler/language versions should just be a happy coincidence. And when it's time to move, you can really take time to ensure your code is properly updated for the new tooling.