Possible to get a warning when using std::move on a const?

[helios]

There is no such promise if we decided not to use const meaningfully in the first place.

I don't know what you mean.

How does it behave differently? It's maybe faster the second time?

The function also allocates memory, possibly lots of it, and only releases it when the object is destructed.

IMO, that behavior shouldn't be part of the contract; it shouldn't dictate the method's interface. As long as the pre- and post-conditions are upheld, an implementation can satisfy them however it wants.

Well, this entire discussion started when I asked for an justification for the isocpp.org assertion, that constness should match logical state. If your reason for doing it is your opinion then fair enough, but that doesn't do anything for anyone else.
I mean, that FAQ makes pretty a strong statement. Is there really no other reason behind it than "because I say so" or "it just feels right"?

[TheIdeasMan]

@helios

Imagine the keyword mutable didn't exist. In a class with a cache value and an expensive function which calculates it, an accessor function which causes the cache value function to be called cannot be const.

By using mutable for the cache value, the accessor functions can still be const, which is what we want, and probably one of the reasons why mutable was invented. As I understand it, that is the point of the idea of Logical versus Physical state of the class.

As mentioned earlier the video by Kate Gregory on isocpp explains the whole thing with examples. Not sure, it might be this one:

https://isocpp.org/blog/2017/12/kate-gregory-its-complicated-meeting-cpp-2017-center-keynote

[helios]

Imagine the keyword mutable didn't exist. In a class with a cache value and an expensive function which calculates it, an accessor function which causes the cache value function to be called cannot be const.

I'm saying that's the way it should be. I don't buy the argument that the memoization table is not part of the object's state. All I've heard so far in defense of that is "it just isn't".

The examples I do buy are the ones I mentioned earlier. The mutable public member one because it's part of the interface, the mutex one because that particular state gets deterministically set then unset every time the function is called.

[mbozzi]

The function also allocates memory, possibly lots of it, and only releases it when the object is destructed

Okay, but so what? Inform the caller in the documentation. We can't reasonably indicate this information by omitting const.

I don't buy the argument that the memoization table is not part of the object's state. All I've heard so far in defense of that is "it just isn't".

It doesn't reflect in the object's interface because it's irrelevant to it. When we call fibonacci(n) we're logically inspecting our particular fibonacci sequence, which never changes. Therefore, the method is const-qualified.

The examples I do buy are the ones I mentioned earlier [...] the mutex one because that particular state gets deterministically set then unset every time the function is called.

What specifically warrants treating the table differently, and why?

I don't know what you mean.

Just re-read my earlier post - if you always or never use const, it no longer has any meaning.

[helios]

Okay, but so what? Inform the caller in the documentation. We can't reasonably indicate this information by omitting const.

I disagree. I think a const function allocating memory in the object is a breach of POLA.

Just re-read my earlier post - if you always or never use const, it no longer has any meaning.

Well, you can't know if the interface that contains either version of average_of_frequency_domain() uses const always, never, or sometimes. It's not part of the example. That's why I said

the second function may be hiding [whether the function needs to modify its input] (depending on context)

What specifically warrants treating the table differently, and why?

On the contrary, I'm saying it should be treated the same. The state of the object when Foo::get_data() enters is the same as when it leaves it (up to non-deterministic behaviors). The same is not true for fibonacci_fn_t::fib_impl(). If fibonacci_fn_t::fib_impl() made a temporary copy that was std::moved() back onto the member before returning I would have no problem.

It doesn't reflect in the object's interface because it's irrelevant to it. When we call fibonacci(n) we're logically inspecting our particular fibonacci sequence, which never changes. Therefore, the method is const-qualified.

This is just a longer way of saying "it just isn't". Everything you're saying hinges on the unsupported premise that the only relevant aspects of an object for a caller are what is returned by its member functions.

[TheIdeasMan]

@helios

Perhaps one can think of it this way:

mutable is an exception (or an allowance say) to the way const works. One of the uses for it is the cache example I have been using.

Apart from that I haven't anything to add.