www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 5868] New: static attribute ignored with public static {} blocks

reply d-bugmail puremagic.com writes:
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



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
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5868


Don <clugdbug yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |clugdbug yahoo.com.au




 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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5868


hsteoh quickfur.ath.cx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hsteoh quickfur.ath.cx



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
prev sibling next sibling parent d-bugmail puremagic.com writes:
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



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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5868




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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5868


bearophile_hugs eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bearophile_hugs eml.cc




 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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5868




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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5868




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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5868


Jonathan M Davis <jmdavisProg gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmdavisProg gmx.com



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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5868





 There's nothing technically wrong with it, but it's misleading.
I think here there's material for a diagnostic enhancement request.
 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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5868




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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5868




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
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5868


yebblies <yebblies gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |yebblies gmail.com





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