I have been tossing this idea in my mind for almost 20 years. The current
schema of overloading operator new belongs to dinosaur era IMO.
If we could provide operator new with the requested type - instead of just
its size (and optionally alignment), then the return type could also be a
custom allocator (rather just void*). This in turn would enable the new
expression to return a smart pointer - rather than a dangerous raw pointer:

smart_allocator operator new(compiler_provided_params,user_provided_params)
value_type { /*...*/};

The corresponding new expression:

auto ptr=new(user_provided_args) value_type {initializer_args};
Would then generate pseudo code sequence like this:

auto ptr = [&}(){
    smart_allocator temp_alloc{ operator
new(compiler_provided_args,user_provided_args) value_type };
    smart_pointer ret=temp_alloc(initializer_args);
   return std::move(ret);
}();

The exact type and number of compiler provided parameters is open to
discussion, but it must at least provide the following functionality:

auto constructor_lambda(compiler_provided_params){
    return [](void * void_this, auto && ... initializer){
        ::new(__none_overloadable_placement__ , void_this) value_type
 {std::forward<decltype(initializer)>(initializer) ... };
    };
};

the multi-lambda in the above pseudo snippet shall correspond to all
accessible overloads of constructors of value_type in the context of
calling new-expression. other functionality such as destructor
accessibility and assignment operator overload set may also be considered,
but avialablity of accessible constructors is of prime essence IMHO.
This proposition is aiming at encouraging the *usage of raw pointers as
observer-only* idiom. I am trying to combine the syntax clarity of *new* with
safety of *make_smart *family of convenience functions. Other benefits
include:

   - passing the whole type - instead of just its size - to the *operator
   new* enables safely conveying meta-data about exact type of object to
   runtime such as *clonabilty *true destructor. One problem with
   traditional *new-expression* is destructor slicing of none-polymorphic
   hierarcies (that this proposition can help avoid):

std::unique_ptr<base> { new derived };// dtor is sliced if base does not
declare it as virtual

smarter_unique_ptr<base> { new(smart_tag) derived }; // can avoid
destructor slicing if uses smart overloading for new


   - Custom return type of *new *enables optimizing data structure of smart
   pointers; e.g it is possible to embed the count of references into the same
   block of allocation as the actual object, enabling superfast reference
   counting.
   - Prohibit lots of issues (double-delete, dangling ptr, memory leak ...)
   resulting from improper pointer initialization.


Regards,
FM.