Skip to content
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

try making co_return strict #165

Draft
wants to merge 1 commit into
base: v24.3.x
Choose a base branch
from

Conversation

bashtanov
Copy link

@bashtanov bashtanov commented Jan 4, 2025

Avoid explicit constructors invocations, c-style conversions etc, stick to the same implicit conversions used for function calls and returns.

The reason I did not just static_assert for U being convertible to T but actually changed the way it is converted is because semantics of T(std::forward<U>(v)) may still be different from these of implicit cast in return v. This test would not pass without it:

struct wild_int {
    int value;
    wild_int(char c)
      : value(c - 10) {}
    explicit wild_int(int i)
      : value(i + 10) {}
};

struct c {
    static wild_int f() { return 42; }
    static ss::future<wild_int> g() { co_return 42; }
};

auto f_res = c::f();
auto g_res = c::g().get();
BOOST_CHECK_EQUAL(f_res.value, g_res.value);

(TODO add the test)

template<typename U>
void uninitialized_set(implicit_tag, U&& v) {
new (this) T(id<T>(std::forward<U>(v)));
}
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AFAIK placement new won't perform an excessive copy or move from an rvalue of the same type returned by id function.
This will need some performance testing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant