I understand your sentiments in your blog post, however as with my suggestion, which is not exactly the same that your blog post uses as example, I still find it an error to return ‘referency’ things from unqualified member functions. As well as returning a referency thing that refers to a parameter that can bind to a temporary (const&,&&) or refers to a non-static local variable.
The latter is always considered an error. Designing and using view classes is extremely tricky and we failed to do so well in several cases. My claim is that the core language with assignment and the many value classes in the standard library that return references non-ref qualified member functions create a hole in the type system that we do not have with free functions. I still consider this something worth thinking about and I do not have the silver bullet as you noticed in your blog. But not having the silver bullet doesn’t mean we should not work on mitigating that monster’s dangers. 

Regards

Peter



On Wed, Nov 11, 2020 at 12:58 PM Peter C++ <peter.cpp@sommerlad.ch> wrote:

The crux of dangling in many cases are member functions returning references (or pointers of views) If those functions would be lvalue-ref-qualified this dangling can not happen.

This is a common misconception. Consult my blog post "Value category is not lifetime":

https://quuxplusone.github.io/blog/2019/03/11/value-category-is-not-lifetime/

–Arthur