Bug 10097 – __ctor, __dtor, and __postblit should no appear in user code

Status
RESOLVED
Resolution
INVALID
Severity
major
Priority
P2
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2013-05-16T09:45:15Z
Last change time
2019-11-03T04:54:30Z
Assigned to
No Owner
Creator
Kenji Hara

Comments

Comment #0 by k.hara.pg — 2013-05-16T09:45:15Z
This code: struct S { this(int) {} this(this) {} ~this() {} } pragma(msg, __traits(allMembers, S)); Would print: tuple("__ctor", "__postblit", "__dtor", "__cpctor", "opAssign") But, the identifiers which starts with double underscore are internal names. I think __traits(allMembers) should not show such internal names.
Comment #1 by k.hara.pg — 2013-05-16T09:48:12Z
However, __postblit and __dtor are already used in Phobos - hasElaborateCopyCoonstructor and hasElaborateDestructor. So, we should support additional __traits to replace the existing usage: __traits(hasCtor, AggrType); __traits(hasDtor, AggrType); __traits(hasPostblit, AggrType);
Comment #2 by wazar.leollone — 2013-05-16T10:26:11Z
(In reply to comment #1) > However, __postblit and __dtor are already used in Phobos - > hasElaborateCopyCoonstructor and hasElaborateDestructor. > > So, we should support additional __traits to replace the existing usage: > __traits(hasCtor, AggrType); > __traits(hasDtor, AggrType); > __traits(hasPostblit, AggrType); How I can get overloads of constructor? struct Foo { this(int){} this(int, Foo*){} } Now I can write: foreach(cur; __traits(getOverloads, Foo, "__ctor")) { //do something } If we'll drop "__ctor" access, we can get any alternative variant to get constructor overloads. May be access to constructor in C++ style is a better way? void delegate(int) ctor = &Foo.this; //this looks like function member in dot expression. void delegate() dtor = &Foo.~this;
Comment #3 by maxim — 2013-05-16T11:27:46Z
(In reply to comment #0) > This code: > > struct S { > this(int) {} > this(this) {} > ~this() {} > } > pragma(msg, __traits(allMembers, S)); > > Would print: > tuple("__ctor", "__postblit", "__dtor", "__cpctor", "opAssign") > > But, the identifiers which starts with double underscore are internal names. > I think __traits(allMembers) should not show such internal names. I think there are some reasons that they should be listed in allMembers (because they are members). However idea with special traits for ctors, dtors and postblit is even better. Anyway this is a minor issue. But the problem is bigger. Dmd internally generates hoards of symbols and does not stop them to be accessed. They can be divided into two categories: 1) ctors, dtors, postblits, fielddtros, fieldpostblits, shared ctors, unittests and others which can be accessed both by internal name and by linking. 2) variables which can be accessed only by internal name. For example, this program compiles and runs: extern(C) int printf(const char*,...); void main() { foreach (i; 0..2) { if (__key5 == 1) __limit6 += 3; printf("%d\n", i); } } and breaks idea about behavior of foreach range. This is just accepts-invalid. So, what you effectively propose is to take three items of first group and make them inaccessible in some circumstances. I think other holes should be closed too.
Comment #4 by iamthewilsonator — 2019-11-03T04:54:30Z
__dtor is needed for dealing with stack allocated classes to call the destructor so I'm going to close this as invalid.