Comment #0 by webhenryblock — 2016-07-14T21:44:24Z
DeclDef says it can contain a constructor, but when I type,
this() {
}
I see this,
t.d(1): Error: constructor can only be a member of aggregate, not module t
I also noticed these errors for destructors and invariants. Do I misunderstand the grammar? I'll make a diff after checking the other productions if I'm not already barking up the wrong tree?
Comment #1 by schveiguy — 2016-07-14T22:19:13Z
I don't think this is an enhancement, it's a bug.
I'd guess that allocators also aren't allowed. It appears that the module DeclDef grammar is a cut-and-paste from classes.
Comment #2 by schveiguy — 2016-07-14T22:19:53Z
(In reply to Steven Schveighoffer from comment #1)
> I don't think this is an enhancement, it's a bug.
Clarification: it's not a bug in the compiler, it's a bug in the spec!
Comment #3 by webhenryblock — 2016-07-14T22:23:15Z
(In reply to Steven Schveighoffer from comment #1)
> I don't think this is an enhancement, it's a bug.
I suppose that's a bug in the Report Bug button on the spec site then! :-)
Comment #4 by webhenryblock — 2016-07-14T22:39:58Z
To be honest, I might have opened a can of worms here. The spec also suggestion you can put
abstract bool x;
at module scope in a D file, which isn't quite right :-)
I suppose I was reading it a bit to literally. I'll leave this ticket open, but now that I'm a page further into reading about D, this looks like quite a large task.
Comment #5 by dfj1esp02 — 2016-07-15T15:04:56Z
Not sure if this is a bug: what's syntactically valid is not necessarily semantically valid, and you're asking for a context-sensitive and bloated grammar, you'll have to duplicate a lot of rules.
Comment #6 by dfj1esp02 — 2016-07-15T15:40:15Z
Imagine a grammar that expresses this rule: "can't refer to `super` in a struct method that is not nested in a class method".
Comment #7 by webhenryblock — 2016-07-15T22:10:27Z
(In reply to Sobirari Muhomori from comment #6)
> Imagine a grammar that expresses this rule: "can't refer to `super` in a
> struct method that is not nested in a class method".
Haha, yes I see. Sorry, I see now that I'm misunderstanding the grammar's purpose.
Comment #8 by schveiguy — 2016-07-18T21:51:48Z
Sorry, but that's lazy. We can easily express the grammar that a module cannot have a constructor (in contrast to your analogy, there is a separate module grammar from classes, so we have a perfect spot to outlaw it).
We put up with a lot of grammar inaccuracies that result in simply ignored attributes. We can do better.
Even if the actual code treats the grammar for modules and classes the same, the documentation can reflect the actual result. Right now, it looks like constructors are allowed.
CC grammar guru Brian
Comment #9 by dfj1esp02 — 2016-07-19T10:30:06Z
(In reply to Steven Schveighoffer from comment #8)
> We put up with a lot of grammar inaccuracies that result in simply ignored
> attributes. We can do better.
You mean you want to disallow this in grammar?
---
pure:
int n;
---
Comment #10 by schveiguy — 2016-07-19T12:11:06Z
(In reply to Sobirari Muhomori from comment #9)
> (In reply to Steven Schveighoffer from comment #8)
> > We put up with a lot of grammar inaccuracies that result in simply ignored
> > attributes. We can do better.
>
> You mean you want to disallow this in grammar?
> ---
> pure:
> int n;
> ---
No, I mean that the grammar allows such things, and they are nonsense (but I agree we shouldn't remove it).
Here, we have something that is plainly wrong in all cases, but the grammar says it's allowed. We can't just say "well grammar can't do everything", when clearly it can reflect this case.
Comment #11 by robert.schadek — 2024-12-15T15:23:50Z