digitalmars.D.bugs - [Issue 5868] New: static attribute ignored with public static {} blocks
- d-bugmail puremagic.com (32/32) Apr 21 2011 http://d.puremagic.com/issues/show_bug.cgi?id=5868
- d-bugmail puremagic.com (11/14) Apr 21 2011 http://d.puremagic.com/issues/show_bug.cgi?id=5868
- d-bugmail puremagic.com (16/16) Jan 26 2012 http://d.puremagic.com/issues/show_bug.cgi?id=5868
- d-bugmail puremagic.com (14/14) Jan 26 2012 http://d.puremagic.com/issues/show_bug.cgi?id=5868
- d-bugmail puremagic.com (20/20) Jan 26 2012 http://d.puremagic.com/issues/show_bug.cgi?id=5868
- d-bugmail puremagic.com (17/21) Jan 26 2012 http://d.puremagic.com/issues/show_bug.cgi?id=5868
- d-bugmail puremagic.com (6/6) Jan 26 2012 http://d.puremagic.com/issues/show_bug.cgi?id=5868
- d-bugmail puremagic.com (18/18) Jan 26 2012 http://d.puremagic.com/issues/show_bug.cgi?id=5868
- d-bugmail puremagic.com (16/16) Jan 26 2012 http://d.puremagic.com/issues/show_bug.cgi?id=5868
- d-bugmail puremagic.com (9/11) Jan 26 2012 http://d.puremagic.com/issues/show_bug.cgi?id=5868
- d-bugmail puremagic.com (8/8) Jan 27 2012 http://d.puremagic.com/issues/show_bug.cgi?id=5868
- d-bugmail puremagic.com (15/15) Jan 27 2012 http://d.puremagic.com/issues/show_bug.cgi?id=5868
- d-bugmail puremagic.com (25/25) Jan 27 2012 http://d.puremagic.com/issues/show_bug.cgi?id=5868
http://d.puremagic.com/issues/show_bug.cgi?id=5868
Summary: static attribute ignored with public static {} blocks
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nobody puremagic.com
ReportedBy: aldacron gmail.com
--- Comment #0 from Mike Parker <aldacron gmail.com> 2011-04-21 05:35:39 PDT ---
The following produces an error for conflicting constructors, "Previous
Definition Different".
class Foo
{
public static
{
this() {}
}
public
{
this() {}
}
}
Remove the curly braces from the public static and it compiles fine. With
anything defined or declared in a public static block, the static attribute is
ignored. I'm sure this used to work, once upon a time. Tested on 2.052 only.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Apr 21 2011
d-bugmail puremagic.com
http://d.puremagic.com/issues/show_bug.cgi?id=5868
Don <clugdbug yahoo.com.au> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |clugdbug yahoo.com.au
--- Comment #1 from Don <clugdbug 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: -------
Apr 21 2011
http://d.puremagic.com/issues/show_bug.cgi?id=5868
hsteoh quickfur.ath.cx changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hsteoh quickfur.ath.cx
--- Comment #2 from hsteoh 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: -------
Jan 26 2012
http://d.puremagic.com/issues/show_bug.cgi?id=5868
Walter Bright <bugzilla digitalmars.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |bugzilla digitalmars.com
Resolution| |INVALID
--- Comment #3 from Walter Bright <bugzilla 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: -------
Jan 26 2012
http://d.puremagic.com/issues/show_bug.cgi?id=5868
--- Comment #4 from hsteoh 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: -------
Jan 26 2012
http://d.puremagic.com/issues/show_bug.cgi?id=5868
bearophile_hugs eml.cc changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |bearophile_hugs eml.cc
--- Comment #5 from bearophile_hugs 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: -------
Jan 26 2012
http://d.puremagic.com/issues/show_bug.cgi?id=5868 --- Comment #6 from Walter Bright <bugzilla 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: -------
Jan 26 2012
http://d.puremagic.com/issues/show_bug.cgi?id=5868
--- Comment #7 from hsteoh 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: -------
Jan 26 2012
http://d.puremagic.com/issues/show_bug.cgi?id=5868
Jonathan M Davis <jmdavisProg gmx.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jmdavisProg gmx.com
--- Comment #8 from Jonathan M Davis <jmdavisProg 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: -------
Jan 26 2012
http://d.puremagic.com/issues/show_bug.cgi?id=5868 --- Comment #9 from bearophile_hugs 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: -------
Jan 26 2012
http://d.puremagic.com/issues/show_bug.cgi?id=5868 --- Comment #10 from hsteoh 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: -------
Jan 27 2012
http://d.puremagic.com/issues/show_bug.cgi?id=5868 --- Comment #11 from Jonathan M Davis <jmdavisProg 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: -------
Jan 27 2012
http://d.puremagic.com/issues/show_bug.cgi?id=5868
yebblies <yebblies gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |yebblies gmail.com
--- Comment #12 from yebblies <yebblies 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: -------
Jan 27 2012