Idea: even more semicolons in items because why not

[mcy]

I propose accepting the following productions, for purposes of consistency with struct K; and struct K {}.

enum Void;
trait Marker;
impl Void;
impl Marker for Void;

These are all equivalent to an empty pair of braces { } where the semicolon is. Note that I do not introduce union Void; since empty unions are illegal. Though, maybe we should parse it anyways to give a better error for it? shrug

I’ll note that struct K; is technically equivalent to struct K {}, as items. The only difference is that the former also introduces an extra item: const K: K = K {};. There really isn’t an equivalent version of this for enum Void;, which would itself be a pretty rare construct.

Moreover, I suggest linting against the following productions.

auto trait Marker { }
impl Marker for Ty { } // where Marker is auto
impl !Marker for Ty { }
impl Ty; // unsure about this one. the only things that should reasonably
         // have empty impls are things generated by macros.

I don’t think we should lint against enum Void {} though, in case we do make enum Void; somewhat more like struct K;. However, the only conceivable thing the expression Void could do is materialize a Void value and immediately panic. This strikes me as an all-round awful idea.

[Ixrec]

Personally, it feels inconsistent and surprising to accept enum Void; but not enum Void{};. My semi-conscious parser just doesn’t see a semicolon as equivalent to an empty pair of braces.

[mcy]

There’s an RFC out by @centril to accept ; as an item, so that enum Void{}; will parse as (enum Void{})(;). This idea is predicated on proposal being accepted.

[ExpHP]

That’s the status quo for struct.