Why can't std::as_const(T &&v) move-return its argument?

Question

Reading Why does as_const forbid rvalue arguments? I understand that we can't convert a rvalue-ref into an lvalue-ref, of course.

But why not move the rvalue-ref into a value and return that, i.e. ?

template<typename T> 
const T as_const(T&& val) { return std::move(val); } 

This ought to work nicely with COW containers as well, as the returned value is const and iterators from it will not cause it to detach.

Maybe some godbolt-ing will answer this though, but I can't think of a given scenario and there are no COW containers easily available there AFAIK.

Update:

Consider this COW container (ignoring threading issues):

class mything {
   std::shared_ptr<std::vector<int>> _contents;

   auto begin() { if (_contents.use_count() > 1) { detach(); }
                  return _contents->begin(); }
   auto begin() const { return _contents->begin(); }
   void detach() {
       _contents = std::make_shared<decltype(_contents)>(*_contents); 
   }
   ...
};

Move would be fast and the const T returned would select the const-version of begin() when used in range-for-loop.

There are also containers that mark themselves as modified so their changes can be sent over network or later synced to another copy (for use in another thread), f.ex. in OpenSG.

Lulita

My guess would be simply that this is not what the function is for: that it means 'make this non-const reference into a const one', not 'make sure I get something const in all cases'. – Globoid

const on a return value (not reference) is basically meaningless – Hypnotism

@Hypnotism not for copy-on-write containers whose non-const begin()/end() functions create a new copy (aka detach) since they expect the contents to change. – Lulita

Returning std::move(val) as T will make a copy of val in any case. Furthermore, return std::move(...) is an anti-pattern that often prohibits NRVO. However, even NRVO won't help when returning an input argument, there will always be copying involved. – Dhu

@Dhu but a move() isn't that a big deal as a copy, even if it can be a slightly bigger deal when moving a container (unless it only has one pointer in it, like a single-linked-list or something). – Lulita

@Lulita a move from a const object is a copy, as you can't "steal" resources from a const object. It's not because the code says std::move that anything is actually moved. – Raila

@Dhu "If a prvalue initially has the type “cv T”, where T is a cv-unqualified non-class, non-array type, the type of the expression is adjusted to T prior to any further analysis." .. it this case T is very much a class, I think? – Lulita

Ok, if we disregard the issue of non-class const T, still your version would return a new instance of T. It would be misleading that an lvalue-ref overload returns the reference to the same object, while the rvalue one - a new object. – Dhu

@Dhu Yeah, it probably is a bit off. I haven't used std::as_const in contexts outside the for-range loop so I can't say much about that. If it was get_const_temporary then either const T or const T& would be more acceptable, perhaps, and that is how I've seen it. But we should probably stop here or move to chat if we want to discuss further. – Lulita

Answer 1

I understand it as an additional feature to have but to avoid some measuses: get a const view to something which has an address.

And because a temporary does not have an address, there should also be no const view of it.

And moving the value rather than just adding const would change it's semantics ( we already have std::move)

And if as_const to a temporary would extend it's lifetime on it's own, then it would waste space if not bound, for example:

{
   as_const(f()); // if the lifetime would be extended
...
 } // not bound, but space wasted

For example as_const adds const to a value rather than to a type, so it's saving some typing like static_cast, add_const etc.

Normaly binding a const lvalue ref to a temporary, would extend the temporary lifetime, for example:

int f() { return 3; }

{
   const auto& x = f();
    ... use x .. ok
}

But something like this would end to a dangling reference:

{
   auto& x = as_const(f()); // one could wrongly think that temporary lifetime is extended, but it's not
    ... x dangles ..
}

Overbear

That's why I suggest returning a value from the r-value ref instead of an lvalue ref, since we can't, AFAIK, return r-value refs from functions. – Lulita

@Lulita - Of course we can. That's exactly how std::move works. – Venereal

@StoryTeller-UnslanderMonica So what I need is std::move_to_const ? :) .. implements as in my question? I can do that. :) – Lulita

Btw, isn't the whole point of an r-value ref that you can move it into a location or similar. So moveing it to a value we return isn't bad.. It like moving something out of a variant and returning it. – Lulita

I think of r-value as a kind of "flag" that it is movable. But if one than really moves from it or not, is IMO another story. – Overbear