www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 10266] New: CTFE: Allow reinterpret casts T <-> T[1]

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

           Summary: CTFE: Allow reinterpret casts T <-> T[1]
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Keywords: CTFE
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: verylonglogin.reg gmail.com



19:54:43 MSD ---
This is necessary if you don't want to branch a templated function in static
array case and just treat everything as a flat static array (i.e. both T and
T[1][1] become T[1]):
---
ref f(ref int i)
{
    return *cast(int[1]*) &i;
}

void g()
{
    int i;
    f(i)[0] = 5;
    assert(i == 5);
}

static assert((g(), true));
---

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




Supporting this would create a *huge* number of corner cases.

For example, CTFE strictly enforces C pointer arithmetic.

int b;
int * p = &b;
++p;  // illegal, can only do pointer arithmetic on pointers to arrays

int[1] n;
int *q = &n[0];
++q; // ok, one past the end of an array is explicitly legal

I'm not sure if that cast leads to well-defined behaviour in C. I suspect that
after the cast, it might not be a genuine array.
I think a 16bit C compiler could legally put b at location 0xFFFC, then after
++p, p would be 0. Which could never happen with a proper array.

Of course all this stuff could be implemented, but sticking to C rules makes
things very much easier, because it eliminates so many of these nasty cases.

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




12:24:11 MSD ---


 I suspect that after the cast, it might not be a genuine array.


I like the idea to not create genuine array here. Just a restricted array for
e.g. `foreach`.

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








 I suspect that after the cast, it might not be a genuine array.


 
 I like the idea to not create genuine array here. Just a restricted array for
 e.g. `foreach`.


Hmmm, I don't know how to do that. This kind of feature is practically
guaranteed to fail, it creates dozens of weird special cases (and they would
all be subtle wrong-code bugs).

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