[Issue 5868] static attribute ignored with public static {} blocks
http://d.puremagic.com/issues/show_bug.cgi?id=5868 --- Comment #10 from hst...@quickfur.ath.cx 2012-01-27 21:12:58 PST --- Yeah, invalid attributes should not be ignored. They should always generate a compile-time error. Just as expressions with no side-effects generate an error when they appear as standalone statements, rather than get ignored. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5868] static attribute ignored with public static {} blocks
http://d.puremagic.com/issues/show_bug.cgi?id=5868 --- Comment #11 from Jonathan M Davis jmdavisp...@gmx.com 2012-01-27 21:24:48 PST --- There are arguments for it which relate to generic programming. It's not that hard to end up with templated code that would have issues compiling if the compiler errored out on invalid attributes for particular instantiations of a template while being fine for others. I agree that ideally the compiler would error out on invalid attributes, but I think that the situation and its effects have to be closely examined before changing the status quo. Regardless of that though, the big problem is convincing Walter. Personally, I'm surprised that the compiler allows invalid attributes in the first place. I have no idea what his thought process was in allowing them and have no idea what it would take to convince him. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5868] static attribute ignored with public static {} blocks
http://d.puremagic.com/issues/show_bug.cgi?id=5868
yebblies yebbl...@gmail.com changed:
What|Removed |Added
CC||yebbl...@gmail.com
--- Comment #12 from yebblies yebbl...@gmail.com 2012-01-28 16:40:00 EST ---
(In reply to comment #11)
It's to do with the way the compiler handles attributes. There are four kinds:
1. shared void func();
2. shared: void func();
3. shared { void func(); }
4. void func() shared;
The first two really evaluate to the third. It doesn't make sense for the
third one to give an error on invalid attributes, as they might be intended to
a bunch of different declarations. While the first one looks like is should be
rejected sometimes, to the compiler they're all the same.
The fourth case is special, in that the storage classes get passed directly to
the function declaration. There is potential here for rejecting invalid
storage classes, but are there any that are actually invalid?
So to answer your question: Having attributes work this way make the parser
compiler simpler. The decision most likely dates from a time when this was one
of D's major goals.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5868] static attribute ignored with public static {} blocks
http://d.puremagic.com/issues/show_bug.cgi?id=5868
hst...@quickfur.ath.cx changed:
What|Removed |Added
CC||hst...@quickfur.ath.cx
--- Comment #2 from hst...@quickfur.ath.cx 2012-01-26 10:27:46 PST ---
This bug also happens without public for static ctors:
class A {
static {
int x;// this is OK, interpreted as static int x
this() { ... } // this is NOT OK, interpreted as non-static this()
}
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5868] static attribute ignored with public static {} blocks
http://d.puremagic.com/issues/show_bug.cgi?id=5868 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||INVALID --- Comment #3 from Walter Bright bugzi...@digitalmars.com 2012-01-26 12:28:27 PST --- Not a bug. Spec sez: The static in the static constructor declaration is not an attribute, it must appear immediately before the this -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5868] static attribute ignored with public static {} blocks
http://d.puremagic.com/issues/show_bug.cgi?id=5868
--- Comment #4 from hst...@quickfur.ath.cx 2012-01-26 12:35:32 PST ---
So the right syntax is:
class A {
static {
...
static this() { ... }
...
}
}
?
Or alternatively
class A {
static { ... }
static this() { ... }
}
?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5868] static attribute ignored with public static {} blocks
http://d.puremagic.com/issues/show_bug.cgi?id=5868
bearophile_h...@eml.cc changed:
What|Removed |Added
CC||bearophile_h...@eml.cc
--- Comment #5 from bearophile_h...@eml.cc 2012-01-26 13:41:06 PST ---
(In reply to comment #3)
Not a bug. Spec sez:
The static in the static constructor declaration is not an attribute, it must
appear immediately before the this
Then is it better for the compiler to give an compile-time error for code like
this? Is this material for a diagnostic enhancement request?
class A {
static {
this() { ... }
}
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5868] static attribute ignored with public static {} blocks
http://d.puremagic.com/issues/show_bug.cgi?id=5868 --- Comment #6 from Walter Bright bugzi...@digitalmars.com 2012-01-26 17:19:02 PST --- I don't think there's anything wrong with the current setup. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5868] static attribute ignored with public static {} blocks
http://d.puremagic.com/issues/show_bug.cgi?id=5868
--- Comment #7 from hst...@quickfur.ath.cx 2012-01-26 17:44:20 PST ---
There's nothing technically wrong with it, but it's misleading. When you write:
class A {
int x;
this(int) { ... }
static {
int y;
this(uint) { ... }
}
}
It appears as though the second ctor is somehow static in some sense, yet it
is not, as the current semantics mean that you can hoist it out of the static
block and still retain the same meaning. Since that's the case, why not
prohibit it from being placed in a static block in the first place?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5868] static attribute ignored with public static {} blocks
http://d.puremagic.com/issues/show_bug.cgi?id=5868
Jonathan M Davis jmdavisp...@gmx.com changed:
What|Removed |Added
CC||jmdavisp...@gmx.com
--- Comment #8 from Jonathan M Davis jmdavisp...@gmx.com 2012-01-26 17:50:01
PST ---
Invalid attributes are usually ignored in D rather than resulting in an error.
So, it's quite consistent that if static {} has no effect on a constructor, the
compiler wouldn't complain about you putting a constructor within the static
block. Now, whether it's _desirable_ that D function that way is another matter
- in general, IMHO it's definitely a negative that invalid attributes get
ignored rather than resulting in errors - but it's definitely consistent with
the rest of the language.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5868] static attribute ignored with public static {} blocks
http://d.puremagic.com/issues/show_bug.cgi?id=5868 --- Comment #9 from bearophile_h...@eml.cc 2012-01-26 18:07:08 PST --- (In reply to comment #7) There's nothing technically wrong with it, but it's misleading. I think here there's material for a diagnostic enhancement request. (In reply to comment #8) Invalid attributes are usually ignored in D rather than resulting in an error. And this is so wrong that it must change. I have zero doubts about this. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5868] static attribute ignored with public static {} blocks
http://d.puremagic.com/issues/show_bug.cgi?id=5868 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #1 from Don clugd...@yahoo.com.au 2011-04-21 05:51:27 PDT --- (In reply to comment #0) The following produces an error for conflicting constructors, Previous Definition Different. I'm sure this used to work, once upon a time. No. It failed even on DMD 0.140 (Nov 2005). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
