Plans for C++/WinRT 3.0 and 4.0

[YexuanXiao]

Currently, there are no clear plans for what changes C++/WinRT will undergo in the future. I believe C++/WinRT could be improved in the following areas:

1. Introduce a wcstring_view type to address critical issue Bug: Undefined behavior in param::hstring(std::wstring_view #1569, which is a breaking change.
2. Change array_view to std::span, which is a breaking change and requires C++20.
3. Use concepts instead of SFINAE to improve compilation speed and error messages, which is requires C++20.
4. Use std::atomic_ref instead of raw synchronization intrinsics to simplify code, which is requires C++20.
5. Use three-way comparison to simplify code, which is requires C++20
6. Merge cppwinrt should not call LoadLibrary anywhere unless new WINRT_REG_FREE define is defined, re-activating regfree behavior #1446 to improve correctness and safety.
7. Change hstring's value_type to char16_t for consistency with box_value (which does not accept wchar_t), which is a breaking change.
8. Deprecate uninit_apartment and provide a RAII class to uninitialize COM, which is a breaking change.

Which of these will be accepted and which will not? Which belong to C++/WinRT 3.0 and which belong to C++/WinRT 4.0?

[DefaultRyan]

Anything that's a breaking change will de facto need to be 4.0 or later.

[DefaultRyan]

Currently, there are no clear plans for what changes C++/WinRT will undergo in the future. I believe C++/WinRT could be improved in the following areas:

1. Introduce a wcstring_view type to address critical issue Bug: Undefined behavior in param::hstring(std::wstring_view #1569, which is a breaking change.
2. Change array_view to std::span, which is a breaking change and requires C++20.
3. Use concepts instead of SFINAE to improve compilation speed and error messages, which is requires C++20.
4. Use std::atomic_ref instead of raw synchronization intrinsics to simplify code, which is requires C++20.
5. Use three-way comparison to simplify code, which is requires C++20
6. Merge cppwinrt should not call LoadLibrary anywhere unless new WINRT_REG_FREE define is defined, re-activating regfree behavior #1446 to improve correctness and safety.
7. Change hstring's value_type to char16_t for consistency with box_value (which does not accept wchar_t), which is a breaking change.
8. Deprecate uninit_apartment and provide a RAII class to uninitialize COM, which is a breaking change.

Which of these will be accepted and which will not? Which belong to C++/WinRT 3.0 and which belong to C++/WinRT 4.0?

A fair number of these are about moving the minimum bar from C++17 to C++20. I'm a fan of adopting C++20 features that improve the developer experience, but raising the minimum is a bigger ask, especially when there are some aspects of C++20 adoption that can break binary compat in some cases (I'm forgetting the specific cases off the top of my head, but I've heard it enough that I don't think I'm completely hallucinating).

For example, for array_view what are the complexity additions to suport std::span overloads instead of dropping array_view? If array_view is dropped, where does that leave com_array, does it retain the old array_view interface? Do we make a parallel implementation, or do we inherit from std::span, (I generally take a dim view of inheriting from 3rd party code that wasn't explicitly designed to be inherited from).

Can we introduce concepts additively? Ditto for three-way comparison?

I'm interested to see what we can learn from possible telemetry and how many of our users are actually using C++20 today.

Outside of C++20...

The LoadLibrary change is still planned to take forward. We just need to fine-tune the approach and "boil the frog", since it can introduce silent runtime behavior changes.

What value is there, other than abstract "consistency" to changing hstring from wchar_t to char16_t? And if consistency is the goal, has anybody investigated the reverse, aka, change box_value to wchar_t? The whole history of Unicode on Windows and the mismatch of wchar_t used for UTF-16 is a long and painful one, but one that is pretty much universally known about. Personally, I'd love to see a fundamental modernization towards Unicode in Windows APIs and types (e.g. explicitly use char8_t to support narrow-character APIs that explicitly use UTF-8, instead of some random code page), but that's a whole other thing.

[sylveon]

I believe the convention is to provide operator std::span, or implement the ranges protocol (ranges::data and ranges::size) in which case a constructor on span exists.