Complex constants

[sotteson1]

ECMA-335 allows for constants, but the values can only be strings or scalar values like int, uint, etc. It doesn't support constant values IntPtr or Guid, for example.

Win32 has lots of constants for types other than string or scalar values, like GUIDs and IntPtr:

From the C headers:

DEFINE_GUID(CLSID_AMMultiMediaStream, /* 49c47ce5-9ba4-11d0-8212-00c04fc32c45 */
0x49c47ce5, 0x9ba4, 0x11d0, 0x82, 0x12, 0x00, 0xc0, 0x4f, 0xc3, 0x2c, 0x45);

#define HBMMENU_CALLBACK            ((HBITMAP) -1)

ECMA-335 allows for a complex type for a field whose constant value is not of the same type. So we can do this:

C#:

public const HBITMAP HBMMENU_CALLBACK = -1;

Which in the metadata is represented with:
.field public static literal valuetype [Windows.Win32.winmd]Windows.Win32.Gdi.HBITMAP HBMMENU_CALLBACK = int32(-1)

We could do the same thing with GUIDs:

public const GUID CLSID_AMMultiMediaStream = "49c47ce5-9ba4-11d0-8212-00c04fc32c45";

It would be up to the projector to figure out how to set the complex type with the string/scalar. What do language projection writers think about this proposal?

[AArnott]

(C# projection author) I think it's a little hokey, but I can't think of a better idea. I believe you're already doing this in some cases (one enum comes to mind) and it's tolerable, so I say move ahead.

[kennykerr]

Wonky but so long as we can parse the field signature and get all of this information it should be doable.

[DefaultRyan]

The C++ projection should be fine with this. We'll want to be sure to document this usage. I bet there is some tooling capable of reading winmds that will be confused by the difference in type between the Field signature and the Constant row (ECMA-335 says this isn't valid in the CLS subset).

So, in the HBMENU_CALLBACK example:

• The Field signature would be HBITMAP.
• The associated row in the Constant table would have a Type of ELEMENT_TYPE_I4, and points at a blob containing the value.