Bug: Surprising winrt::guid_of<> behavior for classes implementing winrt::implements

[forderud]

Version

2.0.250303.1

Summary

I'm struggling to understand the intended behavior of winrt::guid_of<T>(). The function appear to return the same value as __uuidof(T) for most types. However, it behaves very differently for classes inheriting winrt::implements<T...>, where it instead seem to return the interface ID GUID for the first interface in the winrt::implements template list.

I'm not sure if this is a bug or intended behavior, but it does at least seem to have caused a bug in wil::register_com_server (see microsoft/wil#533). I would therefore appreciate if the documentation could either be extended to clarify the behavior, or the behavior changed to avoid counter-intuitive surprises.

Reproducible example

struct DECLSPEC_UUID("5fb96f8d-409c-42a9-99a7-8a95c1459dbd") ICapture : ::IUnknown {
 ...
};

struct DECLSPEC_UUID("BABF401C-D3D2-4B68-8E1A-1F4177F3F49A") Capture : implements<Capture, ICapture, IStringable> {
 ...
};

Expected behavior

__uuidof(Capture); // returns {BABF401C-D3D2-4B68-8E1A-1F4177F3F49A} 
winrt::guid_of<Capture>(); // returns {BABF401C-D3D2-4B68-8E1A-1F4177F3F49A}

Actual behavior

winrt::guid_of<ICapture>(); // returns {5fb96f8d-409c-42a9-99a7-8a95c1459dbd} as expected

__uuidof(Capture); // returns {BABF401C-D3D2-4B68-8E1A-1F4177F3F49A} as expected
winrt::guid_of<Capture>(); // returns {5fb96f8d-409c-42a9-99a7-8a95c1459dbd} which was surprising to me

Additional comments

No response

[github-actions]

This issue is stale because it has been open 10 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[forderud]

Would it be possible to get some feedback on this problem report?

[kennykerr]

This is by design. The guid_of function returns the identifier of the WinRT type. For COM and WinRT interfaces, this is the identifier of the interface. For WinRT classes, this is required to be the same as that of the default interface of the class. You can see this explicitly in the implementation:

cppwinrt/strings/base_identity.h

Lines 7 to 11 in 4c9e03f

	template <typename T>
	constexpr guid const& guid_of() noexcept
	{
	return impl::guid_v<default_interface<T>>;
	}

It is only if and when guid_v is not specialized that it will fallback to using __uuidof where applicable.

[forderud]

This is by design.

Fair enough. Would it then be possible to update the winrt::guid_of documentation to more explicitly state the current behavior?

[kennykerr]

I'm not sure who owns the docs but I've seen various people contribute improvements - there's an "Edit" link on that topic where I believe you should be able to suggest or contribute improvements.

[forderud]

I'm not sure who owns the docs but I've seen various people contribute improvements - there's an "Edit" link on that topic where I believe you should be able to suggest or contribute improvements.

Ok. I just submitted a documentation update proposal in MicrosoftDocs/winrt-related#399. I'm new to WinRT though, so it would be greatly appreciated if you or someone knowledgeable in this area could give some feedback on the wording.

[kennykerr]

Thanks!