Re: Proposal: Add more compile-time asserts to expose inconsistencies.

Hi,

On 2019-11-13 03:23:06 +0000, Smith, Peter wrote:
> From: Andres Freund <andres(at)anarazel(dot)de> Sent: Wednesday, 13 November 2019 6:01 AM
>
> >Peter Smith:
> >
> > Is there a reason to not just make StaticAssertExpr and StaticAssertStmt be the same? I don't want to proliferate variants that users have to understand if there's no compelling
> > need. Nor do I think do we really need two different fallback implementation for static asserts.
>
> >
> > As far as I can tell we should be able to use the prototype based approach in all the cases where we currently use the "negative bit-field width" approach?
>
> I also thought that the new "prototype negative array-dimension" based
> approach (i.e. StaticAssertDecl) looked like an improvement over the
> existing "negative bit-field width" approach (i.e. StaticAssertStmt),
> because it seems to work for more scenarios (e.g. file scope).
>
> But I did not refactor existing code to use the new way because I was
> fearful that there might be some subtle reason why the
> StaticAssertStmt was deliberately made that way (e.g. as do/while),
> and last thing I want to do was break working code.

That'll just leave us with cruft. And it's not like this stuff will
break in a subtle way or such....

Greetings,

Andres Freund