The undocumented wil library is used instead of winrt in several samples

[pjmlp]

Several Microsoft samples like https://github.com/microsoft/Project-Reunion-Samples make use of wil, which most likely refers to https://github.com/microsoft/wil.

No documentation is available at MSDN, nor the rationale why it is being used instead of the winrt namespace, for example wil::com_ptr<>() instead of winrt::com_ptr<>().

This makes it even harder to make sense of what C++/WinRT is all about, now that C++/CX nice tooling has been taken away from us.

[riverar]

+@kennykerr

[andrewleader]

Hey @kennykerr, can you help answer this? Thanks!

[kennykerr]

Agreed, the samples should stick to C++/WinRT. I had a quick look and its being used for wil::com_ptr when it should just be using C++/WinRT's winrt::com_ptr, which is basically the same. There is very little reason why projects (outside of OS components) should be using WIL to begin with. Using it in samples just makes it harder for developers to apply those samples to their own projects.

[DrusTheAxe]

There is very little reason why projects (outside of OS components) should be using WIL to begin with

I respectfully disagree. There's many reasons. C++ Standard Library and C++/WinRT aren't always available or provide sufficient functionality.

If you're referring specifically to C++ consuming WinRT APIs I might be more agreeable (if you don't mind exceptions)

[kennykerr]

You may be right, but there seems to be a lot of overlap. I'd love to see an @oldnewthing style table comparing STL, C++/WinRT, WIL to see what value WIL actually provides over and above STL and C++/WinRT.

[jonwis]

See https://github.com/microsoft/wil/wiki for documentation. The main things that we use WIL for are:

• Wrappers around Windows primitives (lifecycle management, resources)
• Consistent flow-control tools (xxx_IF_FAILED for both exceptional and result-oriented code)
• Reporting and handling errors (machinery under those flow-control helpers)
• Adapting "old style" code to "new style" semantics in various places (errors, callbacks, threading, locking, etc.)

There is some overlap, such as com_ptr. WIL also has wil::com_ptr_nothrow (an upgrade from Microsoft::WRL::ComPtr) for use with result-oriented flow and a wil::com_ptr_failfast for any-error-is-fatal code. Many parts of Windows' internal implementation still use result-oriented flow, even if we'd prefer they move towards modern C++ style and practice.

Unfortunately we can't simply replace wil::com_ptr with winrt::com_ptr easily as we also have code that doesn't yet meet the requirements of using cppwinrt.

Code that started its life inside Windows and is being moved into Project Reunion may similarly start as a mix of the two patterns until we can convert them forward to fully modern C++ with minimal use of result-oriented flow.

I do agree that we should switch to winrt::com_ptr for the samples, as they should represent the code that a customer would write.