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

[Martin Sebor]

On 05/10/2017 04:14 PM, Daniel Santos wrote:
> 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)).

The C committee has discussed extending the set of expressions
that are considered constant in C2X.  A proposal was submitted
last year that, at least in spirit, gained pretty broad support
(the finer details, including the syntax, especially the reuse
of the register keyword, are likely to evolve):

   http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2067.pdf

The C committee's charter for C2X is to increase compatibility
with C++, so new language features with that effect have a good
chance of being considered.

I don't expect C2X to go as far as to add something as complex
as templates but some on the committee are working on enhancing
support for generic programming (via _Generic).  Interestingly,
C11 (by accident) introduced a requirement for implementations
to support true type genericity in the form of the C11 atomic
APIs.  It may not be too far out there to propose to generalize
the underlying machinery and make it available to programs (as
opposed to just the standard library alone).

Martin