Re: [Tinycc-devel] Opinions on constexpr being added to C2X?

[Elijah Stone]

To be honest, this seems like a _very_ limited use-case, and probably not 
one that is worth to support.

Sorry.

I think that either:

1. Compile-time computation needs to have very few restrictions; in this
   case it is very useful, but impractical to implement; or

2. Compile-time computation needs to have very many restrictions (as in
   the linked proposal); in this case, the span of potential use cases is
   very limited.

Because of the restriction on recursion, it is not even possible to do 
something like compute a hash from an aggregate at compile-time.  Even 
were this restriction lifted, though, because mutation is not possible it 
would not be possible to _produce_ any useful object of aggregate type.

(I will mention that I do not think it would be more difficult for tcc
 to support recursive constexpr than to simply support one constexpr
 function calling another.  But this is largely beside the point.)

Assuming you do move forward with the proposal, please ensure that 
compilation can be done in a single-pass fashion.  That is, this should 
not be allowed:

constexpr int g(void);
constexpr int f() { return g(); }
constexpr int x = f();
constexpr int g() { return 7; }

Nor this:

constexpr int g(void);
constexpr int x = g();
constexpr int f() { return x; }
...

This is probably fine, though:

constexpr int g(void);
constexpr int f() { return g(); }
constexpr int g() { return 7; }
constexpr int x = f();

It is impossible to sanely compile D without coroutines because its 
declarations are unordered.  Don't go down that path.

 -E

On Thu, 14 Oct 2021, Marcus Johnson wrote:

> There's a new proposal to add it, and the standard is especially interested in 
> hearing from small compiler devs their opinions on such a feature.
>
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2851.pdf