But what is the intent when you pass a `std::unique_ptr const &'? I really don't know.

I could see it as a way of stating "This pointer is not supposed to outlife the function, so it should never be stored", but its really not clear at all, and even when used throughout the codebase, would still be ambiguous.

I totally agree with the notion, that if you don't care about ownership at a certain point, you just pass plain pointers/references. If you ie. have a composite object, where all leaves have a backpointer to their owner, there is no need to have the leaves know about the actual storage type of their owning composite. The composite will outlive the leaves, so each leave gets a Composite*. The additional benefit is that now composites can be stored however they want - as a unique_ptr, shared_ptr (if some code requires it), or some custom memory managment scheme - the code will still work. Whereas if you force "void setParent(const std::unique_ptr<Composite>& parent)", it would mean that the parent would have to be a unique_ptr all the time. An additional bonus of not using unique_ptr through your interface, if you will.

There will be some exceptional circumstances where you want to transfer ownership of the pointer to the function, which is when I you pass an std::unique_ptr.

TBH, I found that quite commonly. Ok, I don't use custom allocators throughout my codebase, but when you just replace every regular occurence of "new" with "std::make_unqiue", you'll often call a function with eigther "std::unique_ptr<> func()" if you want to create a new object, or "void func(std::unique_ptr<>&& ptr)" if you want to set an object. (IDK if std::unique_ptr could or would still be used if you used a complete memory allocation managment scheme, but since I have little experience with it, take my opinion with a grain of salt).

Just for future reference, when adding .get() in the sample case above, you still have to use * to identify the pointer. So: *myPtr.get()

This is weird, you shouldn't need to do that.

The idea is that you wrap an object in a std::unique_ptr<> to express it has a single owner at all times.

One object has that std::uniqe_ptr as object. That object owns the wrapped object. It can do "*" and "->" operations, just asif the std::unique_ptr<> object is a pointer to the wrapped object, ie

class X {
  std::unique_ptr<Y> mine;

  void q() {
      ...
      mine->f();  // Access the 'f' function of the 'Y' object.

For other (non-owning) objects, you give out bare pointers

Y* X::getMine() { return mine.get(); }

this means they use the wrapped object, but do not own it.

They do something like

void Z::g(X &x) {
    Y* y_ptr = x.getMine();
    y_ptr->f();
    ....
}

So yeah, you do get a double "*" indirection, but never on the pointer you ".get()" on, as it doesn't live in Z, it lives in X.

Just for future reference, when adding .get() in the sample case above, you still have to use * to identify the pointer. So: *myPtr.get()

This is not correctly stated. You need to use the unary * operator here to dereference the pointer returned by get() (not "identify," that makes no sense). This is because you're using the expression as an argument to a function call where a reference, not a pointer, is expected. This is not necessary if you are using the result of get() as an argument to a function where a pointer is expected.

I haven't been keeping up with C++ best practices in the last few years, but it would seem to me that taking a const reference to std::unique_ptr<Foo> is confusing.

I would expect most of the time you just want to pass around a pointer or reference to Foo, and the ownership stays with the caller. There will be some exceptional circumstances where you want to transfer ownership of the pointer to the function, which is when I you pass an std::unique_ptr<Foo>. But what is the intent when you pass a `std::unique_ptr<Foo> const &'? I really don't know.

So to the original post, no, because the intent is not clear.

See, that's where I'm confused because I see nowhere where @cozzie asked that, only where they asked about passing a *std::unique_ptr<T> as an argument to a T const& parameter.

Perhaps cozzie can clarify his question more with a small code example?

Yup, it appears I interpreted the question to mean a const reference to the std::unique_ptr, as opposed to that of the owned object.

Still an interesting subject to discuss :)