Compile-time constants to replace preprocessor macros in configuration files?

[ilg-ul]

I'm considering extending one of my projects with a configuration tool inspired by eCos CDL (to configure C++ programs), and, looking to the future, I'm trying to figure out how such a configuration tool is expected to work with Carbon.

In C/C++ the usual way to pass configuration data is via an #include "config.h" where several preprocessor macros are defined, and later the code can test for the macros presence or use the values to define the size of arrays, etc.

In Carbon, which, if I got it right, does not have a preprocessor, I expect such configurations to be implemented with compile-time constants, booleans for simple yes/no choices, integer for sizes, etc.

However, I was not able to figure out how this mechanism is expected to work... :-(

Could someone provide an example how a file with such configuration constants may look like, and how it should be included in other files?

Thank you in advance.

[jonmeow]

This isn't a design that's been fully designed out yet, but metaprogramming will exist in some form, and this kind of use case would probably use let, e.g. let HasFooApi: bool = false;. Whether there's a separate constexpr equivalent keyword isn't something that I think has been discussed.

[L4stR1t3s]

Whether there's a separate constexpr equivalent keyword isn't something that I think has been discussed.

What would you do if you don't have a separate constexpr keyword? Consider everything that is const as constexpr as well? That won't work IMO because not everything that is constant at run-time is also constant at compile-time. You could go pretty far with that, and make a lot of code work at compile-time, but not everything:
const auto id = glCreateShader(GL_VERTEX_SHADER); // Create an OpenGL vertex shader, returns id of the shader on the GPU
Even if you made glCreateShader work at compile-time (no technical reason you couldn't) it would be pretty useless since the id would not be valid at run-time.
And how would you determine whether to evaluate something at compile-time, or at run-time? I would like to be able to generate random numbers at compile-time for example, but definitely not all random numbers. If the same random number function can be used at compile-time and run-time, then some sort of distinction would have to be made syntax-wise.
Or this would mean that the same function could not be used but we need separate functions, but it would be rather cumbersome to have to define all functions twice if you want to use them at compile-time and run-time.

[ilg-ul]

Even if the details are not yet clear, compile-time constants are mentioned in the design documents, so I expect them to be available, in one form or another, otherwise metaprogramming will not be complete.

[jonmeow]

@ilg-ul Similar to having it be a .h file for C++, I'd assume the starting point would be .carbon file for Carbon and using standard inclusion mechanisms. I don't think see any reason why this would be special-cased.

@L4stR1t3s While you raise some good points, I don't really have any references to point you to because metaprogramming and compile-time evaluation just hasn't been a priority for the design work done so far.

[L4stR1t3s]

@L4stR1t3s While you raise some good points, I don't really have any references to point you to because metaprogramming and compile-time evaluation just hasn't been a priority for the design work done so far.

@jonmeow That makes me a little uneasy, because meta programming and compile time evaluation are going to become increasingly more important in the future, and for Carbon to succeed it will have to make a real difference in those areas IMO. The issues with meta programming and compile-time evaluation in C++ are often related to these features being added to an already existing language. I hope Carbon doesn't run into similar issues in the future by assigning a low priority now. Or at least that in the future decisions made now can and will be overturned if it turns out meta programming and compile-time evaluation are negatively impacted by them.

[ilg-ul]

Similar to having it be a .h file for C++, I'd assume the starting point would be .carbon file for Carbon and using standard inclusion mechanisms. I don't think see any reason why this would be special-cased.

@jonmeow, I tried to find some more details in the proposals, and in p0107 there are long arguments related to importing packages and libraries, but apparently there is nothing similar to passing .h files to C/C++.

I don't say that using packages/libraries for passing configuration constants is wrong or impossible, just that there is no discussion explaining how it is supposed to be.

Also in p0339 it is said this proposal does not include any syntax for constants. This is expected to be revisited later.

There might be other interesting things in the proposals, but since they are quite difficult to browse through, I did not find them.

So, it looks like the idea to fully replace the preprocessor with metaprogramming is only a desire, not a concrete proposal. :-(

[L4stR1t3s]

I think there is a speed and memory issue with using compile-time constants as a replacement for preprocessor macros. Preprocessor macros are evaluated before compilation, meaning that potentially a lot of code is removed before compilation. If the decision of which code to use or not is deferred to the compilation then this will have a negative impact on speed and memory while compiling.

[ilg-ul]

Right, but apparently the decision to not include a preprocessor has been already made, so I'm trying to figure out how things are expected to work without it.

Personally I completely avoid macros in C++, but I think that configuration constants and conditional compilations are features that should be present in any language that plans to compete in the space of C++ applications, especially embedded applications, which require an even higher degree of compile-time configurability.

[mossaiby]

Of course C/C++ pre-processor does much more than just #ifdef and #ifndef, so compile-time constants cannot replace current functionality on their own. Configuration problem is so simple compared to advanced use of pre-processor. What can be done for those cases?

[L4stR1t3s]

Personally I completely avoid macros in C++

I have a hard time believing that. Unless our definition of a macro is not the same? In C++ anything that uses #define is considered to be a macro as it will be replaced whenever it is found by the preprocessor.
#define FLAG I am a macro!
#define VERSION 1 I am a macro!
#define SUM(a, b) a + b I am Spartacus a macro!
I can believe someone not using the third macro style, but never using the first and second macro style? I would be flabbergasted!

I understand the sentiment, macros in C++ are one of the worst features of the language IMO, but sadly I don't think they can entirely be avoided when using C++.

What can be done for those cases?

I also fear that Carbon can not entirely avoid a pre-processing step, as it is the most efficient way of dealing with code configuration IMO. But I am aware that opening that door is dangerous, because who knows what might sneak in as well.

[ilg-ul]

I have a hard time believing that.

Technically you are right, all preprocessor definitions are called macros, but I differentiate between object-like macros, which I accept for configuration constants, and function-like macros, which I avoid at all cost.

I also fear that Carbon can not entirely avoid a pre-processing step, as it is the most efficient way of dealing with code configuration IMO

I am a bit confused now, initially I thought the same, but when I read in the proposals that the preprocessor functionality will be covered by metaprogramming, I thought that perhaps the design team had some inovative ideas how to do it.

Now I'm not so sure, it looks like the subject was not even considered thoroughly. :-(

[mossaiby]

Technically you are right, all preprocessor definitions are called macros, but I differentiate between object-like macros, which I accept for configuration constants, and function-like macros, which I avoid at all cost.

Not all the things can be done without object-like macros, and many things than can be done, need weird C++ tricks that make the code much harder to read and understand (at least for me). Yet, I agree pre-processor is a two-way sword, but I do not have a definite replacement for it.