As the OP I should have been more responsible in keeping the thread on the
correct track. While I have ideas about other matters being discussed under
current thread, I do believe that tuple vector or structural binding or OT
here. I appreciate any positive/negative feedbacks on changing the
overloading syntax/semantics of operator new. I do exactly mean to code
like this:

unique_ptr<int> uptr= new(unique) {1};//deduce int from decltype(*uptr);
*uptr==1;
auto sptr= shared_ptr<int> {new(unique) {2}};//deduce int from
decltype(*sptr); convert from unique_ptr to shared_ptr; *sptr==2;
int* ptr= new(unique) int{3}//compile error: "operator
new(decltype(unique)) int" follows smart rules

regards,
FM.

‫‪Farid Mehrabi‬‏ <‪farid.mehrabi_at_[hidden]‬‏> در تاریخ پنجشنبه ۱۷ سپتامبر
۲۰۲۰ ساعت ۱۳:۵۶ نوشت:‬

> 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.
>

-- 
how am I supposed to end the twisted road of  your hair in such a dark
night??
unless the candle of your face does shed some light upon my way!!!