A few years ago, I introduced an optimization for https://github.com/microsoft/cppwinrt that allowed methods and properties to be attributed as noexcept to improve call site code generation. While all WinRT methods must return an HRESULT on the ABI, noexcept methods always return S_OK and are thus infallible. This does not change the way C++ code "looks and feels" but C++/WinRT would mark such methods noexcept in the C++ sense which allows the C++ compiler to avoid a bunch of exception handling overhead at call sites, reducing code size.
In Rust, the noexcept can further be used to avoid having to unwrap method calls that are known to be infallible. This also reduces error handling overhead but additionally simplifies implementations and call sites as method return values may be used directly without unwrapping.
The test included with this update illustrates the impact of this change. Consider the following IDL definition of an interface:
A few years ago, I introduced an optimization for https://github.com/microsoft/cppwinrt that allowed methods and properties to be attributed as
noexcept
to improve call site code generation. While all WinRT methods must return anHRESULT
on the ABI,noexcept
methods always returnS_OK
and are thus infallible. This does not change the way C++ code "looks and feels" but C++/WinRT would mark such methods noexcept in the C++ sense which allows the C++ compiler to avoid a bunch of exception handling overhead at call sites, reducing code size.In Rust, the
noexcept
can further be used to avoid having tounwrap
method calls that are known to be infallible. This also reduces error handling overhead but additionally simplifies implementations and call sites as method return values may be used directly without unwrapping.The test included with this update illustrates the impact of this change. Consider the following IDL definition of an interface:
In Rust, the first batch of methods all return a
Result
while the second do not:Fixes: #2991