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


--- Comment #0 from Denis Shelomovskij <verylonglogin.reg gmail.com> 2013-06-04
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



--- Comment #1 from Don <clugdbug yahoo.com.au> 2013-06-18 00:31:47 PDT ---
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



--- Comment #2 from Denis Shelomovskij <verylonglogin.reg gmail.com> 2013-06-18
12:24:11 MSD ---
(In reply to comment #1)
 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



--- Comment #3 from Don <clugdbug yahoo.com.au> 2013-07-04 01:23:30 PDT ---
(In reply to comment #2)
 (In reply to comment #1)
 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