[Issue 16267] New: Windows modules are missing key information
via Digitalmars-d-bugs
digitalmars-d-bugs at puremagic.com
Mon Jul 11 19:41:34 PDT 2016
https://issues.dlang.org/show_bug.cgi?id=16267
Issue ID: 16267
Summary: Windows modules are missing key information
Product: D
Version: D2
Hardware: x86_64
OS: Windows
Status: NEW
Severity: trivial
Priority: P1
Component: druntime
Assignee: nobody at puremagic.com
Reporter: TeddyBear12311 at gmail.com
1. Many windows modules are not marked @nogc, preventing them from being used
in nogc code. This can be seen by doing an inverse search for nogc on the
windows modules. There are many. Since these are bindings to C/win32, it's
obvious they do not rely on the GC and should be marked so.
This is probably the case for many bindings and not just the win32 ones.
winreg.d and objbase.d are just a few.
Should extern(Windows) always be marked nothrow @nogc automaticaly(search and
replace the windows files)?
2. Many enumerations have no name(defined globally I guess) which prevents
converting values to names. e.g., One can't do to!string(cast(???)val)) to
convert error messages to their string equivalents. To get around this I'm
duplicating the enum structures and naming them so I can fill in the ???.
winerror.d is the main concern but all enums should be named so one can convert
their values to their corresponding names.
It would be better to be able to make allow a named enum to both be named and
global.
e.g.,
global enum NamedEnum { }
Alternatively, maybe create a construct that allows one to get the enum
containing the member.
e.g.,
cast(GetEnum(S_OK))0 returns "S_OK". GetEnum returns the anonymous enum in
some way(has an internal name).
--
More information about the Digitalmars-d-bugs
mailing list