To better understand the C++ type system, I have endeavored to write a pointer wrapper class which propagates constness similar to std::experimental::propagate\_const:

```
template <typename Pointee> class Ptr {
public:
  Ptr() = delete;

  explicit Ptr(Pointee *);

  Ptr(const Ptr<Pointee> &) = delete;
  Ptr(Ptr<Pointee> &&);

  Ptr<Pointee> &operator=(const Ptr<Pointee> &) = delete;
  Ptr<Pointee> &operator=(Ptr<Pointee> &&);

  ~Ptr()  = default;

  const Pointee *operator->() const;
  Pointee *operator->();
  const Pointee &operator*() const;
  Pointee &operator*();

private:
  Pointee *mPtr;
};

```

The wrapper is intended to provide near raw pointer like behavior while also enforcing a kind of 'deep' const correctness and guarding against unintentional aliasing.

To this end, the copy constructor and copy assignment operator are deleted:

1. To prevent unintentional aliasing of the pointed-to object by
copying from a Ptr.
2. To prevent non-const access of a const
pointed-to object by copying a const Ptr into a non-const Ptr.

However, the above design has two unfortunate consequences.

1. A const Ptr cannot be moved into a either a const or non-const Ptr. When C++17's mandatory RVO does not apply, this means that a const Ptr object cannot be returned from a function.
2. Due to C++17's mandatory copy/move-elision, in certain situations a non-const Ptr can be constructed from a const Ptr even though no such viable constructor exists. For instance, the code below will compile just fine (ignore the memory leak/raw new for the purpose of demonstration):

```
const Ptr<int> allocateImmutableInt(int val) { return Ptr<int>(new int(val)); }

void foo() {
  Ptr<int> immutableInt = allocateImmutableInt(0); // Initializes non-const Ptr from const Ptr 
  *immutableInt = 100;  // Oops, changed value of 'immutable' object
}

```

The first problem can be partially solved by introducing a move ctor that accepts a const rvalue reference (although this feels somewhat strange and non-idiomatic):

```
  Ptr(const Ptr<Pointee> &&);

```

However, this actually worsens the second problem. Now a const Ptr can be move constructed into a non-const Ptr even without mandatory move/copy-elision. As far as I can tell, to get around this issue we would need a so called 'const constructor', ie a constructor which can only be invoked to produce a const object:

```
  Ptr(const Ptr<Pointee>&&) const;

```

Even if c++ supported such a constructor, the second problem would still remain, as c++17 specifically ignores cv-qualification and the viability of constructors when deciding if mandatory move/copy-elision can be applied when initializing an object. There does not currently appear to be a way to ask c++ to check if a copy/move would be viable before applying mandatory copy/move elision to object initialization.

As far as I can tell, std::experimental::propagate\_const suffers from these same issues. I am wondering if I have encountered a fundamental limitation of c++, or if I am designing the Ptr wrapper incorrectly? I am aware that these issues can likely be eliminated by creating two types, a Ptr for non-const access and ConstPtr for const-only access. However, this defeats the purpose of creating a const-propagating wrapper in the first place.

Perhaps I have just stumbled upon the reason why both an iterator type and a const\_iterator type exist.