I'm tearing up bug 4533 to have member-related alias problems in a separate bug. You can alias members from *outside*: class A { void foo() {} } alias A.foo goo; This compiles. It fails only if goo is called but should fail already at the alias declaration. Also, Andrej Mitrovic found a similar issue documented, but not implemented: In the docs (http://www.digitalmars.com/d/2.0/declaration.html), there's this code: void main() { struct S { static int i; } S s; alias s.i a; // illegal, s.i is an expression alias S.i b; // ok b = 4; // sets S.i to 4 } But this [illegal expression] will compile.
I think your first example should be legal because you can create a delegate out of the alias and an instance of A. void delegate () dg; dg.ptr = new A; dg.funcptr = &goo; dg(); // this works
I'm not sure. The existence of .funcptr seems to contradict http://www.digitalmars.com/d/1.0/type.html#delegates "There are no pointers-to-members in D, but a more useful concept called delegates are supported." See also bug 2557. Applies to D1 as well, though new A must be cast. Moreover, you don't need to go through an alias - DMD 1.062 accepts even dg.funcptr = &A.foo; But non-static members of structs/classes/unions are still compile-time entities, and they have properties.
(In reply to comment #2) > I'm not sure. The existence of .funcptr seems to contradict > > http://www.digitalmars.com/d/1.0/type.html#delegates > "There are no pointers-to-members in D, but a more useful concept called > delegates are supported." Just after that it says: "Delegates are an aggregate of two pieces of data: an object reference and a function pointer.". You must always have a pointer to a member, then you add a context and gets a delegate. How about static members, you can have pointers to those, regular function pointers. I don't know why the docs are written like that. Probably because the concept is a little different compared to C++'s member pointers. D's delegates are basically just syntax sugar for a C++'s member pointer and a instance of the same class. > See also bug 2557. > > Applies to D1 as well, though new A must be cast. Moreover, you don't need to > go through an alias - DMD 1.062 accepts even > dg.funcptr = &A.foo; I used an alias because an alias was used in the first example. > But non-static members of structs/classes/unions are still compile-time > entities, and they have properties.
(In reply to comment #3) > (In reply to comment #2) > > I'm not sure. The existence of .funcptr seems to contradict > > > > http://www.digitalmars.com/d/1.0/type.html#delegates > > "There are no pointers-to-members in D, but a more useful concept called > > delegates are supported." > > Just after that it says: "Delegates are an aggregate of two pieces of data: an > object reference and a function pointer.". It really should say "a pointer to a non-static member function". > You must always have a pointer to a > member, then you add a context and gets a delegate. How about static members, > you can have pointers to those, regular function pointers. I don't know why the > docs are written like that. Probably because the concept is a little different > compared to C++'s member pointers. D's delegates are basically just syntax > sugar for a C++'s member pointer and a instance of the same class. No, because delegate types don't care the least what class the function is a member of. This is why they're more useful - whatever is using the delegate need not know anything about the class, and so (for instance) a library can use a delegate just like a plain function pointer.
Commit pushed to https://github.com/D-Programming-Language/d-programming-language.org https://github.com/D-Programming-Language/d-programming-language.org/commit/eedb99442ac037495ae12c3a7732aad72a074bf6 fix Issue 4545 - Alias to members possible without 'this' instance
I'm not sure what to do with this. I did make some minor tweaks to the delegate description. If more should be done, please be specific. I don't agree that the behavoior Tomasz is reporting is a bug; it's expected.
--- alias s.i a; // illegal, s.i is an expression --- is still in the docs and compilable.
(In reply to comment #7) > --- > alias s.i a; // illegal, s.i is an expression > --- > is still in the docs and compilable. And it's not a bug.
(In reply to comment #8) > (In reply to comment #7) > > --- > > alias s.i a; // illegal, s.i is an expression > > --- > > is still in the docs and compilable. > > And it's not a bug. As I understood everywhere in `statement.dd` "illegal" means incorrect statement and it shouldn't be compilable. So "illegal" in `expression.dd` is expected to do so too. You reply means for me that those "illegal" statements doesn't compile with dmd but it is implementation specific and an other D compiler may compile them fine and it will result in undefined behavior. It will be a hell. Or am I mistaken somewhere?
My mistake. I should read more carefully.
*** This issue has been marked as a duplicate of issue 4062 ***