[RFC] GCC 8 Project proposal: Extensions supporting C Metaprogramming, pseudo-templates

[Daniel Santos]

On 05/10/2017 04:24 AM, Jonathan Wakely wrote:
> Just because there's already one way to do something doesn't mean
> better ways to do it are bad.

I'm only speaking out of jealousy being that most of my recent work has 
been in C.

>> hadn't gone so far as to investigate using this new attribute on functions
>> since we already have __attribute__((const)).  I haven't used this before so
>> maybe I'm not aware of something that makes it unusable for such cases?
>> Which of course raises the question if __attribute__((const)) would work out
>> since it's only currently used on function declarations (and pointers to
>> function declarations, but I don't fully understand what that is doing in
>> handle_const_attribute).
> __attribute__((const)) is not a substitute for constexpr, it's not
> even in the same ballpark. It says the function doesn't touch global
> memory, it doesn't mean its return value is a constant expression, so
> you can't do:
>
> int f() __attribute__((const));
> int f() { return 1; }
> int i[f()];
>
> I don't think __attribute__((const)) is useful for your goal.

Well my primary goal is programming with values that are constant in the 
compiler.  There is no language in any C specification (that I'm aware 
of) for a "compile-time constant", but the concept is very important.  
So just because some expression is a compile-time constant doesn't mean 
we morph into a "constant expression" (as per the spec), even with 
__attribute__((const)).

Perhaps I can separate this project into two stages: a const/constprop 
and a constexpr.  The first stage behaves as little more than a 
collection of optimizer hints, extra warnings/errors and fixes to some 
missed optimization opportunities, while the second implements a 
constexpr for C.  The first stage should lay a lot of the framework for 
the second, but the second probably deserves a formal specification (and 
I will certainly have to read up on changes in C++14 and 17 that I'm 
behind on).  I can state the rationale for the "const" or "constprop" 
portion of this, but before adding a constexpr to C, I think a good 
rationale should be written up and examined as well.  I am in support of 
this as I've encountered many areas where I saw it could be useful -- 
use in combination with GCC ({ statement expressions }) particularly 
comes to mind.

I still have a lot to learn about the cgraph and I know next to nothing 
about how profile guided optimization works, but an ideal implementation 
of a const/constprop attribute should include a mechanism (perhaps via 
-fopt-info?) to inform the programmer when it turns out that their 
optimization hint don't look like such a good idea. :)

I appreciate everybody's feedback!  Thoughts?

Also, still a bit new to GCC, am I missing any formal steps that should 
be taken prior to pursuing such changes?

Thanks,
Daniel