Why not allow empty code blocks?

[Marko Rauhamaa]

BartC <bc at freeuk.com>:
> On 29/07/2016 20:43, Terry Reedy wrote:
>> So put in 'pass' whether or not there is no debugging code,
>> commented-out debugging code, or debugging code that runs, or whatever.
>
> But that's inelegant.
>
> The language requires that blocks always contains 1 or more
> statements. Fair enough, except that 0 statements are often needed so
> that a dummy statement - 'pass' - is required just to keep the code
> legal.
>
> That's untidy, as is your suggestion to keep the dummy statement lying
> around anyway so that the number of statements will always be N+1 and
> can never reach 0 as N changes.

Yes, untidy, albeit only slightly. What you gain is visible blocks.

The gods have spoken and have decided for visibility over philosophical
elegance.

I *have* been hit with analogous untidiness in classic C, which didn't
accept empty structs or empty arrays. I was generating C arrays from a
compiler and--annoyingly--had to place special checks in the compiler to
place a dummy element in an array where none would be generated
naturally.

I have also had to spend some time debugging some segmentation faults
caused by #ifdef's and surprising sizeof calculations in (classic) C and
(modern) C++. Look at this structure:

   struct S {
       int x[0];
   };

Gcc claims sizeof(struct S) == 0 in C and C++.

Well, that's natural, right?

How about:

   struct S {
   };

Now gcc claims sizeof(struct S) == 0 if the language is C but
sizeof(struct S) == 1 if the language is C++.

That's because Stroustrup is allergic to 0-size data structures the way
GvR is allergic to 0-size blocks.


Marko