www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 9953] New: manifest constants of reference types should be illegal

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

           Summary: manifest constants of reference types should be
                    illegal
           Product: D
           Version: D1 & D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: clugdbug yahoo.com.au



---
enum X = [1,2,3];

void main()
{
   assert( X.ptr is X.ptr);
   assert( X is X );
}
---
Both asserts fail at runtime, because they are equivalent to

   assert( [1,2,3].ptr is [1,2,3].ptr);
   assert( [1,2,3] is [1,2,3] );

It would be OK for X to be an int[3] array, but not a slice.
Fundamentally, a reference enum type doesn't make sense. They can't have an
address.
This is the root cause of bug 4397.

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


bearophile_hugs eml.cc changed:

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



This bug report seems for associative arrays too, then.

This bug report is about an old and significant problem of D. Disallowing all
enum reference types seems a little harsh, but I don't know if there are better
solutions.

One problem with this proposal is that there is probably some D code around
that uses enum dynamic arrays and associative arrays (I have stopped using them
in my code since some time), and this proposal will break that code.

One advantage of disallowing enum dynamic arrays is that this avoids a
performance trap, because they get rebuild at every usage point, and this in
the middle of a loop is a waste of time.

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


Andrej Mitrovic <andrej.mitrovich gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrej.mitrovich gmail.com



07:15:52 PDT ---
If we're going to do this we might as well introduce it in 2.063, since this
release will have breaking changes related to this. 

For example const/immutable fields with initializers will no longer be
implicitly static, and people might end up changing them to manifest constants.
If they were l-value initializers it's going to cause further problems when
this issue is implemented (hence why it should be done sooner rather than later
to avoid fixing code two times).

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