Grammar inconsistencies with empty blocks {} and semi-colons.

[brendanzab]

struct A;           // ok
impl A;             // ok
trait B;            // error - must be `trait B {}`
impl B for A;       // ok
enum C;             // error - must be `enum C {}`
extern;             // error - must be `extern {}`
fn foo();           // error - must be `fn foo() {}`

The error on fn foo(); should probably stay, but I've included it for completion sake.

[bstrie]

Nominating for Well-Defined.

[emberian]

All of these make sense, but they are inconsistent.

[catamorphism]

Accepted for well-defined

[brson]

I don't think the block-less fn or extern make sense, but agree the others should allow no block.

[thestinger]

A block-less function would be ambiguous in traits.

[alexcrichton]

I've opened #9336 to disallows impl ...; because I think those should follow the pattern of "requiring braces".

I believe that struct A; should be valid, however, because our syntax for tuple-structs is struct A(...); (note the semicolon). If you leave off the tuple, then it seems like it'd make sense to still retain the semicolon.

Basically, I would consider #9336 as closing this issue, but others may feel differently.

[lilyball]

I agree with @alexcrichton. struct A; makes sense to leave as-is, everything else should be disallowed.

[brson]

I guess we should discuss this in the meeting.

[sfackler]

It'd also be nice if struct Foo {} were legal. Is there a good reason that the compiler specifically forbids it?

[nikomatsakis]

Foo { } as an expression literal is ambiguous in the parser, I believe, though I can't remember why.

[Kimundi]

The problem are cases like this:

match Foo { } { }

See #3212, #3192 and #5167

[Kimundi]

Why do we want to forbid impl ...; ? It could be very useful for traits that only "tag" a type, without actually adding new functionality.

I also think that allowing enum ...; to define an custom uninhabited type should be legal and would be useful.

What makes sense to me:

struct A;           // allow
struct A{}          // forbid because ambiguity
impl A;             // allow
impl A{}            // allow
trait B;            // allow
trait B{}           // allow
impl B for A;       // allow
impl B for A{}      // allow
enum C;             // allow
enum C{}            // allow
extern;             // forbid, useless
extern{}            // forbid, useless
fn foo(){}          // allow
fn foo();           // forbid, ambiguous in traits

The reasoning behind allowing both variants for most of the cases is that there are two possible situations:

1. You intentionally declared an item as being empty. Then ; is shorter, and familiar from the struct neccessarity.
2. You're re factoring your code or are in the process of writing it, and your item either doesn't contain anything yet or all code is currently commented out. Needing to replace the {} with ; back and forth in those cases would be irritating.

(Unless the limitation for unit structs is also a problem for enum or trait definitions, then they need to be forbidden too)

[alexcrichton]

The main reason for forbidding it is consistency. Right now these all mean the same thing, so why not have only one way to do them? In the future we could decide to make ; and {} have separate meanings on a per-item basis, but for now we think it's best to forbid ; where it's not necessary.

[alexcrichton]

Closed by #9336