https://issues.dlang.org/show_bug.cgi?id=22033
--- Comment #2 from Iain Buclaw <[email protected]> --- (In reply to Walter Bright from comment #1) > I'm not sure what good this will do. As wchar_t is a macro, it gets replaced > with a C type by the preprocessor, and ImportC will never see it. Was thinking about possible portability issues, and I was referring to internally within the compiler it's a macro "string", which gets parsed and resolved as the appropriate AST type. e.g: These are defaults --- #define WCHAR_TYPE "int" #define PTRDIFF_TYPE "long int" #define WINT_TYPE "unsigned int" Which could be overridden by the backend target. If these eventually point to their respective special cpp macros __WCHAR_TYPE__, __PTRDIFF_TYPE__, __WINT_TYPE__, etc... then of course these will be all be expanded by the preprocessor leaving us not having to deal with it. --
