Thanks for the follow up!

You are wrong but this is not probably the best place for such a discussion. Some of the issues in the (ab)use of const reference in C++ can be seen here:

https://stackoverflow.com/a/4705871/320726

Const correctness is obviously very useful when your compiler stops you from modifying a const object. Additionally its impact reaches further than just compiler errors (binary size, memory usage, etc). The biggest obstacle for const-correctness is developer laziness.

There may be a case where you do want to wrap a reference: to pass strong types by references. Here is an article that presents that need if you’d like to have a look.

C++ const correctness idea is in my opinion indeed badly broken and, more importantly, not so useful and way overrated in the C++ community. But in this very specific case I’d say that it behaves “logically” and “intuitively” (up to the limits these words can have in a mess like C++).

None that I can see.

I’m glad someone had pointed this out. It seems the wrapper would never be intended to be used with a reference type, so just disallow it. Am I missing a potential use case?

(6) If a typedef-name ([dcl.typedef], [temp.param]) or a decltype-specifier denotes a type TR that is a reference to a type T, an attempt to create the type “lvalue reference to cv TR” creates the type “lvalue reference to T”

See https://timsong-cpp.github.io/cppwp/n4659/dcl.ref

So we have:

T = int
TR = int &
cv TR (here) = int & const (NOT int const & – a const reference to non-const, not a non-const reference to const, as you wrote)
created type = int & (because the cv part is then conveniently dropped)

I think the rules were written in this way because they didn’t want to suddenly allow references to references, but at the same time make argument forwarding (where this scenario would occur particularily often) behave much the same as if they were allowed. It’s also consistent with the fact we can write through a int *const & (a reference to a const pointer to int) by using the unary operator *, confusing as it is in this context.

You probably have noticed that I’m really split here: It makes sense why they did that, but it’s still very unexpected and could easily lead to some major bugs.

Okay, thanks for sharing your experience Edoardo!