Closed FranckRJ closed 2 months ago
Not an expert in the implementation approach, so can't really comment more. It's ultimately about implementing something that works and makes sense, as this is a tool. (and haven't had a chance to progress that other open PR yet).
The scenario makes sense that it should work for Return (but of course can't work for AlwaysReturn)
There are also std::is_rvalue_reference, and std::is_lvalue_reference, but not sure if they would work nor be the best approach either.
A critical bit is to have enough test coverage, in case we need to change the implementation of course .
It's ultimately about implementing something that works and makes sense
Yeah, I guess that moving a value if you're explicitly calling std::move
on it is the behavior the makes the most sense, even when it's a copyable value. I'll go with that.
(and haven't had a chance to progress that other open PR yet).
If you're talking about #310 / #280 I've been a bit lazy with it, I'll look into merging it this weekend (for real, I just need to remember how it works because I've forgotten since the last time I read it), I'll fix the conflicts myself if there's any don't worry.
Now the object passed to
Return(o)
is always move-returned if it is passed by rvalue reference, even if it can by copied. The goal is that if the user pass it bystd::move
they probably don't want it to be copied (maybe it can increase a counter somewhere and they don't want it to) and it will also fix issues with types where you can't properly detect if they're copyable or not likestd::vector
.Tests should be added to ensure this behavior (object is not copied even if it has a copy constructor).
@malcolmdavey Do you think this behavior is OK or do you see an issue with it ?
This is only supported by the
Return
function that takes a single object, it should be supported byReturn(o1, o2, o3)
.A very strange thing happened while implementing that feature, it seems the
template <typename U = T>
trick doesn't work well withstd::is_reference
: https://godbolt.org/z/hjfKaq1dWThe compiler complains that
func(T&& t)
conflicts withfunc(const T& t)
. It's true that they conflict, becauseT = int&
so once we replace T we get something likefunc(T & && t)
andfunc(T & const & t)
which collapse tofunc(T & t)
andfunc(T & t)
. The issue is thatfunc(T&& t)
should be disabled by SFINAE becauseT
is a reference, so it shouldn't cause an error, and it's what happen when usingstd::is_copy_constructible
, so why doesn't it work withstd::is_reference
?Because this trick doesn't work I used the "inherit partially specialized class" method instead.
Should fix #327.