https://issues.dlang.org/show_bug.cgi?id=24158
Walter Bright changed:
What|Removed |Added
See Also||https://issues.dlang.org/sh
https://issues.dlang.org/show_bug.cgi?id=24158
--- Comment #7 from dave287...@gmail.com ---
I think I was a little unclear with my previous comments. What I meant is that
these enums are inserted by the compiler into the C code. But they are really D
enums that happen to come from a C file. They
https://issues.dlang.org/show_bug.cgi?id=24158
--- Comment #6 from Walter Bright ---
> it seems like the more that examples “just work” the better.
I completely agree with that, but we also can't break things.
--
https://issues.dlang.org/show_bug.cgi?id=24158
--- Comment #5 from Walter Bright ---
A .di file has D semantics, even if it was generated from a .c file. Hence, it
will always be imperfect, subject to the impedance mismatches between D and C.
If the C semantics of a string literal were changed
https://issues.dlang.org/show_bug.cgi?id=24158
--- Comment #4 from dave287...@gmail.com ---
So the problem is that the string literal is being treated with C semantics in
a D file, when you want it treated with D semantics as it is the result of a
preprocessor-created enum.
--
https://issues.dlang.org/show_bug.cgi?id=24158
--- Comment #3 from dave287...@gmail.com ---
One of the issues with the current state is that if you generate a .di file
from the C file, you get a D enum with the expected behavior, but if you
directly import the C file, you trigger the reported
https://issues.dlang.org/show_bug.cgi?id=24158
--- Comment #2 from Walter Bright ---
The problem is at expressionsem.d(4188):
if (sc && sc.flags & SCOPE.Cfile)
e.type = Type.tchar.sarrayOf(e.len + 1);
else
e.type =
https://issues.dlang.org/show_bug.cgi?id=24158
Walter Bright changed:
What|Removed |Added
CC||bugzi...@digitalmars.com
--- Comment #1
