• via Digitalmars-d-bugs (37/37) Jul 11 2016 https://issues.dlang.org/show_bug.cgi?id=16267

via Digitalmars-d-bugs <digitalmars-d-bugs puremagic.com> writes:

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 puremagic.com
          Reporter: TeddyBear12311 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).

--