Add support for simple arithmetic expressions in bitfield size about p4c HOT 8 CLOSED

We actually had a prototype for this at some point.
One important issue is the following: if we allow a full expression language for expressing widths, then the greater-than sign will make the grammar ambiguous: you don't know whether > is greater-than or the closing of the "template": bit<a > b ? c : d>. So the grammar for expressions will have to require parentheses: bit<(8+8)>. This is a usability concern. The alternative to restrict the expression language disallowing comparisons sounds like a bad idea.

from p4c.

Requiring parentheses in that context sounds reasonable to avoid the grammar ambiguity.

I would expect the common case for this would be having #define symbols that are sums of other #define symbols, and it is common practice to put parens around such expression anyway, to avoid syntax problems with the context of the C preprocessor textual substitution.

I haven't checked, but is it a workaround to this limitation in P4-16 to have one const be initialized via an arithmetic expression of other values defined as const, and use the const name as the width?

from p4c.

We only need to require the parentheses for expressions involving a > token (including >> or >=), though doing so does involve some (minor) rule duplication in the grammar.

from p4c.

I'm curious how C++ deals with that ambiguity. This program actually compiles and runs fine:

template <bool V> struct foo { int value = V ? 10 : 20; };

int main() { return foo<1 < 2>().value; }

from p4c.

from p4c.

You want a tricky case, consider:

template <int V> struct foo {
    int value = V ? 10 : 20;
    foo(int a) : value(a) {}
    operator int() { return value; }
};

int main() {
    return foo<1 > (2)>(3);
}

from p4c.

Ah yes, that's a good point. C++'s grammar interprets > in that case as closing the template argument list. That's considerably less impressive.

(FWIW, I'm familiar with how to handle this technically; I was more curious about what behavior they specified, but wasn't able to quickly find the appropriate section in the C++ standard.)

from p4c.

I think that this issue can now be closed permanently.

from p4c.