www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 10097] New: __ctor, __dtor, and __postblit should no appear in user code

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10097

           Summary: __ctor, __dtor, and __postblit should no appear in
                    user code
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: major
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: k.hara.pg gmail.com



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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 16 2013
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10097




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);

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 16 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10097


Igor Stepanov <wazar.leollone yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wazar.leollone yahoo.com



10:26:11 PDT ---


 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;

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 16 2013
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10097


Maxim Fomin <maxim maxim-fomin.ru> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |maxim maxim-fomin.ru



---


 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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 16 2013