Thanks for your proposal @PhilippFinke1988

I think this proposal makes sense, and we could consider it.
However there are some implications that would make this challenging to introduce:

• compiler.cppstd has to be removed in conanfile.py recipes for packages that are pure C, because it doesn't apply and it is wrong.
• If we introduced compiler.cstd, the opposite would happen, conanfile.py recipes for C++ packages would have to remove it, because otherwise it would be be affecting.
• The number of C++ recipes is huge, this cannot be introduced without breaking.
• There is a compatibility.py plugin default implementation dedicated to provide default binary compatibility for different compiler.cppstd. That should also be extended for compiler.cstd, but that would be a combinatoric explosion for most cases, exclusively C or C++ binaries (not a mixture of them, in that case, the combinatorics will still hit). We should investigate this and propose some solution.

That means that we would need some recipe opt-in for this feature:

• We have been considering the languages = "C" (or "C++") recipe attribute for some time
• This attribute can be used as an opt-in for further automation at the recipe level
• The opt-in would be implemented by automatic removal of compiler.cstd if languages is not defined

Taking this complexity in mind, it will be challenging to prioritize this for the short-term, there would be quite a few other priorities. I am assigning this as 2.X roadmap, in the meantime, it might be approached by injection of tools.build:cflags, or might require hardcoding it in the build system scripts (basically what was largely done in Conan 1.X for cppstd)

@memsharded Thanks for the fast reply and I'm happy to hear that you consider my proposal. You're totally correct that this is a rather complex feature request and I understand it cannot be done in the short-term. As we're currently still using Conan 1.X in our company and planning to migrate to 2.X in the long-term. So we'd be happy to see this feature in a future 2.X release. Until then we'll surely find a workaround for this issue based on the ideas you provided.

@memsharded Is there already any decision to introduce the languages attribute? We're planning to migrate to Conan 2.X soon and would like to have this feature to avoid several migration iterations on all of our packages.

Thanks for the ping @PhilippFinke1988

We haven't been able to prioritize this yet, we have been very busy with the stabilization of 2.0, migration of ConanCenter to 2.0, and also releasing already 17 releases with some very demanded features (https://blog.conan.io) like package-lists, cache save/remote, sources backup, metadata files, etc.

I think we want to tackle this when possible, let me assign it a fixed milestone and a look-into label.

Resuming this to discuss with the team.

Alternatives:

• settings.cstd vs settings.compiler.cstd. The former is easier to opt-in, 1 line declaration in settings.yml, but allows worse control of flags and validation from different compilers
• Discuss the compiler.cstd defined in profile but discarded unless language = "C", ... to avoid breaking every C++ package
• compatibility.py is still a bit too slow to do this, unless for language = "C" only, maybe? Should we prioritize the speed of this check?

Quick questions:

Would adding a new compiler.cstd subsetting that is automatically removed in every recipe unless language = "C", ... is defined in the recipe, could it be breaking somehow?

Would it be preferable that when a profile/cli defines compiler.cstd=xxx (not None), every package_id for every C++ package that do not depend on the cstd would change and require a new binary?

I am starting the proposal in #16028, testing and feedback welcome.