This is meant to be a discussion before I write a formal proposal.
My presentation is not very clean, so please forgive me.
I wrote this in a proposal style already, but it is not final in any way.
Please tell me what do you think.
Is my estimation of the importance of this problem realistic?
Is my solution tractable?
Does it break any C++ 14 code not already broken in 17/20?

*The problem*

Writing a generic library that need to create objects of the types it uses,
is impossible to implement correctly in C++ 20 without havy
type-based-metaprogramming.

Why? because concepts know nothing of storage, and by extension, on the
correct value semantics usage of these objects (should I copy, move,
forward, allocate them on the heap?).
This means that in-order to extract the value semantics (and dispatch
accordingly) requires heavy SFINAE magic.

This exposes a hole in the object model introduced in C++ 17.

We'll consider a single toy example that illustrates all of the problems
this causes (by the way, the `std::error` type proposed as part of the
"Herbceptions" proosal suffers from the same problem).

If you can write the example below correctly, then you must understand the
problem.

If you want to see the core issue, skip the following sub-section.
If you want to understand why it will be an issue of major importance after
concepts ship, read the example code first.

Toy example: lazy_addable_wrapper library

Look at a toy example of a concepts-based generic library that caches `+=`
operations on a value and applies all when requested.

Consider this library as abuilding block of two other generic libraries:
1. A "safe array smart-pointer" library that does not enable out of bounds
access by remembering the original arrays used to create the pointers.
2. An expression template library that can convert `a += b += b` into `a +=
(2*b)` at compile time (consider the type used to be inefficient to move,
such as matrices).

```c++
template <Addable A>
struct lazy_addable_wrapper
{
     //special member functions skipped for breviety
    template <typename B = A>
    requires std::is_convertible_v<B, A>
    constexpr lazy_addable_wrapper(B &&b) : cached_additions{},
starting_value(std::forward<B>(b))
    {
    }
     template <Movable B = A>
    requires Addable<B>
    constexpr lazy_addable_wrapper & operator+=(B &&a)
    {
          cached_additions.emplace_back(std::move(a));
         return *this;

    }
     // we still need forwarding reference because we want to allow prvalue
references to non-movable types to choose this overload template<Copyable B
= A> requires Addable<B> && !requires Movable<B> constexpr
lazy_addable_wrapper& operator+=(B&& a) {
 cached_additions.push_back(std::forward(a)); return *this; }
    template <Movable B = A>
    requires Addable<B> constexpr lazy_addable_wrapper
&operator+=(lazy_addable_wrapper<B> &&other)
    {
          (*this)+=
std::forward<decltype(std::forward<lazy_addable_wrapper<B>>(other).starting_value)>(std::forward<lazy_addable_wrapper<B>>(other).starting_value);
           std::move(std::back_inserter(cached_additions),
 std::make_move_iterator(other.cached_additions.begin()),
 std::make_move_iterator(other.cached_additions.end()));
          return *this;

    }
     template <Movable B = A>
        requires Addable<B> && !Copyable<B>
    constexpr lazy_addable_wrapper & operator+=(const
lazy_addable_wrapper<B> &other) = delete;
     template <Movable B = A>
    requires Addable<B> && Copyable<B>
    constexpr lazy_addable_wrapper &operator+=(lazy_addable_wrapper<B>
&&other)
    {
           (*this)+=
std::forward<decltype(std::forward<lazy_addable_wrapper<B>>(other).starting_value)>(std::forward<lazy_addable_wrapper<B>>(other).starting_value);
           std::move(std::back_inserter(cached_additions),
 std::make_move_iterator(other.cached_additions.begin()),
 std::make_move_iterator(other.cached_additions.end()));
          return *this;

    }
     template <Copyable B = A>
        requires Addable<B> && !Movable<B>
    constexpr lazy_addable_wrapper & operator+=(const
lazy_addable_wrapper<B> &other)
    {
          (*this)+=
std::forward<decltype(std::forward<lazy_addable_wrapper<B>>(other).starting_value)>(std::forward<lazy_addable_wrapper<B>>(other).starting_value);
           std::move(std::back_inserter(cached_additions),
 other.cached_additions.begin(), other.cached_additions.end());
          return *this;

    }
    constexpr A&& operator*() &&
    {
          return std::accumulate(cached_additions.begin(),
cached_additions.end(), std::move(starting_value), [](auto &&lhs, auto
&&rhs) { return std::forward<decltype(lhs)>+=
std::forward<decltype(rhs)>(rhs); });

    }

private:
     std::vector<A> cached_additions;
     A starting_value;
};
//deduction guides skipped for breviety

static_assert(CrossTypeAddable<lazy_addable_wrapper<int[10]>, ptrdiff_t>,
"What?");
static_assert(CrossTypeAddable<
    lazy_addable_wrapper<
        lazy_addable_wrapper<int[10]>>,
    lazy_addable_wrapper<ptrdiff_t>>, "Wierd, and problematic for
multi-dimensional arrays");
```

I counted at least 4 bugs that cause these static assertions to fire (there
are probably more).

Two of them are fixable "inline".
One requires to make specializations to the entire templated class.
Can you list all of them?

The second static assertion would fire, and it is inheritly unfixable in
C++ 20.

All of these bugs come from the case of non-copyable non-movable types.
They still bind to the references (as they are prvalues), but then, the
function body fails to compile.

The core of the problem
One of the most fundamental invariants of C++'s value semantics:

*User defined types are equivalent to builtin types*

This is true when we consider glvalues but not for *prvalues*.

With C++ 17's guaranteed copy elision, elision became part of the object
model, but users can't possibly write code that depends on it.
For example:

```c++
int arr[10][12];
lazy_addable_wrapper arr_ptr(arr[3]);
wrapper+=3+= lazy_addable_wrapper( lazy_addable_wrapper(arr[7]) += (-5));
```

Where all required constructors, conversions functions and deduction guides
are implemented correctly - this would fail to compile because we are
binding an rvalue reference to a const object (the array reference is
decays into a const pointer).

If we used the builtin array type, this would work due to array-to-pointer
decaying.

Why should the commitee solve this problem?
*1. One of the long term goals of the committee is trying to make generic
code easier to write *
 A new defect in the C++ object model was introduced in C++ 17 with
guaranteed copy elision.
This problem was not pronounced yet, because it only affects generic code.
- After concepts becoming wide-spread with the release of C++ 20, generic
code would be more common.
- Binding prvalues to universal references would be thought as
almost-always-a-bug just like "slicing".
*2. Generic C++ 17 wrapper libraries transitioning to concepts would cause
a behaviour change in user code.*
Consider an existing complete wrapper library written in C++ 17.
It disallows prvalues, as it cannot treat them properly.
If the library wants to refactor to using concepts instead of ugly
metaprogramming, then the concept would also have to disallow NonCopyable
and NonMovable types.
This would mean the concepts won't be satisfied by these types.
But if the concept is used elsewhere in a prvalue manner (which is the case
for the toy example - the matrices use case), then this use case is broken,
or we fragment our concept hieriechy.

If the concept is a standard library one, or in a different library (which
will probably become common in a few years from now) then this requires
forking the concepts library to maintain backward compatibility with this
use case.

*3. This is a huge broken invariant of the object model*

*4. The proposal aims to add prvalues references, which is one step closer
to an RAII based object model and guaranteed Ultimate Copy Elision.*
The unique property of prvalues in the object model is that they are "the
unique way to refer to their result object in the entire program" (which is
the core reason for delaying it's creation to when it is actually used).
This is really a `unique_ptr` to the storage location of the result object,
where the destructor of the unique_ptr is what starts the lifetime of the
result object.
Extending this analogy with further language extensions (`restrict`
qualifier) would make the language more efficient by default.

*5. This proposal resolves some of the objections to Herb-ceptions
exception propogation zero-overhead guarantee*
Throwing an lvalue in the Herb-ception proposal is not guaranteed to be
zero overhead for the same reason NRVO is not guaranteed by the language in
any way.
Throwing a prvalue is OK, and catching by `prvalue` reference does not
materialize it.
This is achievable with the correct implementation of `std::error` type
that treats prvalues differentely then other types.
In fact, the response to this proposal is

Core proposal - *first class **prvalue references.*
Strawman syntax (not essential at all, please no bikesheding): `T !&&! t`
is a prvalue reference of type `T` with alias name `t`.

`t` does not behave like a regular value, as taking it's address is
forbidden, or assigning it (because it is not a glvalue, but a prvalue) and
if you want a materialization conversion, you need to case away `pr`-ness
via `std::move` or a hypothetical `std::materialize`.

Forwarding references would also bind to prvalue references.

Placement new expressions taking `prvalues` reference arguments is the only
way of the core language to perform a materialization conversion on a
`prvalue` reference.

`prvalue` references behave like aliases to objects, and they need to be
the unique owners of the lifetime of their result object (otherwise they
can't control materialization).

This means that they behave like "`unique_ptr` to the prvalue's lifetime,
where the destructor materializes them".

To fix the toy example we would need to add
```c++
namespace std
{
template<typename T>
constexpr T && materialize(T !&&! t)
{
    aligned_storage_t<sizeof(T), alignof(T)> storage;
    T &!!& unique_storage_ref = std::move(new (&storage) T(t));
    return unique_storage_ref; //guaranteed copy/move elision as we return
a prvalue, and so the above line will be performed on the caller stack frame
}
}

template<Addable A>
struct lazy_addable_wrapper
{
    //...
    A operator*() !&&! //cv qualifier
    {
        return {*std::materialize(*this)};
    }
    template<MovableOrCopyable B = A>
    A operator*() && //cv qualifier
    {
        //same as before
    }
     template<Copyable B = A>
     A operator*() & = delete;
```

Can you spot more new bugs in this code?

Extension Proposal
Just as move semantics needed to integrate with the language, this new type
of reference needs a deep integration as well.
I have an outline, and it also solves the problem of transferring this
value semantic information, but I won't bother with publishing it in one
go (again...) as it would cause this to be too large.
In short, for this `prvalue` reference to integrate well, we need a
mechanism to transfer the ownership of a `prvalue` just like a return
statement behaves like a lifetime extension of a prvalue.

In fact, the lifetime extension rules could be reframed in terms of prvalue
references (and that would convert many dangling reference bugs into
compile time errors).

This mechanism must be part of the core object model, and it should behave
similar to the semantics of the `restrict` qualifier in C.

Summary

Handling of prvalues by generic code is a major hole in the object model
that needs to be fixed.
The simplest solution is the most direct one - add a reference
corresponding to this value category.
This solution is benefitial especially if integrated correctly in the
language (safer and more efficient language, makes vocabulary types truly
zero-overhead).