In #64 when I made actor utilize Proto generated assignment operators, I missed that Phoenix copy assignment operator was not producing a lazy expression, instead it simply copied the state over. I do not know why that was done in the first place, the previous behavior is not logical to me, and the current one is more justified, however after thinking thoroughly there is not a lot of use cases for it, the only I had come with is:
#include <boost/phoenix.hpp>
#include <iostream>
int main()
{
using namespace boost::phoenix;
int i = 0, j = 123;
auto ri = ref(i);
(ri = ref(j))();
std::cout << "i=" << i << ", j=" << j << "\n";
}
Since the behavior was broken 6 releases (2.5 years) ago, what is enough time to some one to spot the change and report a regression, but we have not received any, and the new behavior has a little value, I think it is better to simply remove the copy assignment operator, because it will allow us to solve naturally the issue with the -Wdeprecated-copy warning (otherwise we need either to define copy constructor and it will break code that relies on actor being an aggregate, or suppress the warning what currently impossible on GCC).
In #64 when I made actor utilize Proto generated assignment operators, I missed that Phoenix copy assignment operator was not producing a lazy expression, instead it simply copied the state over. I do not know why that was done in the first place, the previous behavior is not logical to me, and the current one is more justified, however after thinking thoroughly there is not a lot of use cases for it, the only I had come with is:
Since the behavior was broken 6 releases (2.5 years) ago, what is enough time to some one to spot the change and report a regression, but we have not received any, and the new behavior has a little value, I think it is better to simply remove the copy assignment operator, because it will allow us to solve naturally the issue with the
-Wdeprecated-copy
warning (otherwise we need either to define copy constructor and it will break code that relies onactor
being an aggregate, or suppress the warning what currently impossible on GCC).Closes #83 Closes #97