-
Notifications
You must be signed in to change notification settings - Fork 249
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] UFCS disable [[nodiscard]] #305
Comments
And implemented because it was accepted, as shown by the result that follows it. |
There's already macros for annotating functions in |
I guess that it will not be accepted until MSVC does not have support for that. |
It's OK. That's why they're macros. |
For this one, I'm not sure what the right resolution is. We could make the UFCS macros unconditionally expand to include (General note: I'm distracted with the upcoming WG21 Varna meeting and will be slow to follow up on issues/PRs until after that.) |
On the eve of the Varna meeting, I've made enough progress on this question over the past couple of weekends that I now think I have an answer, for which I've:
Thanks everyone! I look forwarding to picking up on handling PRs in 2-3 weeks after we all recover from the WG 21 Varna meeting... |
The Wiki's
This isn't the case for parameters. I've been wondering how Cpp2 should support unnamed parameters and function type-ids. See also 3 different design suggestions that support
Shouldn't this link to #231 instead? |
Support `_ =` as a discard operation - for example, `_ = vec.emplace_back(a,b,c);` - emitted as `(void)`, not `std::ignore =` because the latter doesn't work with `void` returns and we want to support generic code where there might or might not be a return value in a given template instantiation Make UFCS calls unconditionally add [[nodiscard]] always - note: only added on compilers that support C++23's P2173 Take back `_ :=` as an anonymous deduced variable syntax - the name can be anonymous or the type can be anonymous, but not both - yes, it would be easy to support making both anonymous (it did work before this commit, which had to explicitly add a check to disable it) - rationale: if that were allowed to keep the returned object alive, that syntax would be dangerously close to '_ = f();' to discard the returned object, which is exactly opposite in a fundamentally important way (lifetime!) and such importantly opposite meanings deserve more than a one-character typo distance - explicit discarding gets the nice syntax because it's likely more common - but this shouldn't be any hardship because cases that use a type are still just as easy, e.g., `lock_guard`; before this commit `_ := lock_guard(mut);` worked, and after this commit that's disallowed but it's just as easy to write `_: lock_guard = mut;` - to make this natural also for `finally`, I just got rid of the `finally` and `finally_success` helper functions, and gave those names to the types... it's a simpler design and I think an improvement in its own right, and `_: finally = code;` is slightly simpler to write (e.g., saves `(` `)` `;`, for example see `pure2-types-order-independence-and-nesting.cpp2`) Remove return type from `contract_group::set_handler` - not needed, since we already have `get_handler` if the current value is of interest Add reflection `default_to_*` functions for `make_*` functions that ignore the returned bool - arguably a clearer API, makes calling code intent more readable
In the current implementation of cppfront (aa70d09), the following code:
Generates (skipping boilerplate):
And when compile with cpp1 compiler (clang++-14 in my case):
Only one unused result is identified -
CPP2_UFCS(ptr1, a, &m);
generates no warning.The issue is caused by
CPP2_UFCS()
macros are eventually lambdas called in-place (Immediately Invoked Function Expressions). The lambda has no[[nodiscard]]
attribute - this is already proposed: P2173R0. I have checked on my compiler - I modified the macro to (notice that[[nodiscard]]
is added after the capture list):And the result is:
The text was updated successfully, but these errors were encountered: