Add macro for compile-time parsing of `GUID`s

[yotamofek]

Suggestion

Similar to uuid!

[kennykerr]

That's not a very compelling argument. 😉

I don't see a strong case for adding this macro as there are already ways to construct a GUID at compile time.

[yotamofek]

GUID is (mostly) a Microsoft-specific alias for a UUID, they are both 128 bits and formatted as hex byte groups, separated hyphens.
uuid is a de-facto standard Rust crate, with a lot more traction than windows-rs, created and maintained by people with a lot more experience and expertise in Rust.
The fact that the uuid! macro exists is a very compelling argument that it is useful.

You say there are already ways to construct a GUID at run-time. Let's take bf967a9c-0de6-11d0-a285-00aa003049e2 for example (this is a real GUID that I want to have as a constant in my team's project). There are the two options currently available:

const GUID1: GUID = GUID::from_values(3214310044, 3558, 4560, [162, 133, 0, 170, 0, 48, 73, 226]);
const GUID2: GUID = GUID::from_u128(254663878541565595792987702975796365794);

I obviously also need to add the human-readable representation as a comment since otherwise it'll be a hurdle for anyone trying to figure out what this constant is.
Does this really seem like a viable alternative to what the macro I implemented provides?

const GUID1: GUID = guid!("bf967a9c-0de6-11d0-a285-00aa003049e2");

[kennykerr]

The mere existence of a macro in some other crate is not a compelling argument for its addition here, however expertly the authors wrote it. You could for example make an entirely different argument that windows-rs should just depend on that crate. I'm not suggesting that, I'm just pointing out that there are different options and solutions you may not have thought about.

You can also write the following, which is a lot more readable or recognizable:

GUID::from_u128(0xaf86e2e0_b12d_4c6a_9c5a_d7aa65101e90)

[kennykerr]

You can of course write something like GUID::from_str as a const fn. Is there a reason why a macro is preferable?