>  >> Anyone who is able to check their pointers before use, is equally able
>  >> to assign 0 to deleted pointers.
>  >
>  > {
>  >    T* p = new T;
>  >     Dll_fn_takes_by_Copy (p);
>  >    delete p;
>  > }
>  >
>  > Show me how.
>  >
>  >
>
> Now you are being silly.
>
> 😂 ...no seriously...it is a honest question.
> How can check if Dll_fn_takes_by_Copy assigned nullptr to the copy of p?
>

Making "delete p;" assign nullptr to "p" will not affect the /copy/ of
"p" taken by the function.  The ownership semantics implied by the name
of your function and what you are trying to do with it - with standard
"delete" or your suggested version - are so badly messed up that the
code is beyond all hope and needs a redesign.

That's an example chosen on purpose to illustrate the case, don't take it as a real world code.
You have to use it to understand the following:
"You are passing a copy of an owning pointer to an opaque function which has a bug."

No change to the language, improvement or otherwise, can make
nonsensical code suddenly work.



>  >
>  > But library implemented and low level will definitely use raw
>  > pointers....just show me how many std::vector implementation uses smart
>  > pointers for its internal data pointer.
>  >
>
> How standard library implementations are written is totally irrelevant.
>
> Very relevant...stl implementation are the goto to anyone who wants to
> crank up his level of C++ expertise. Most students  i see,  copy the
> standard implementation, even if they have the tools to do better.

Real-world implementations of the C++ standard libraries would be an
extraordinarily bad choice of example for anyone wanting to improve
their C++ skills.  Implementations are full of arcane coding that few
people will ever want to see, along with lots of implementation-specific
stuff, short-cuts, uses of poorly documented compiler extensions that
exist solely for implementations of the library, and other non-portable
and risky code that should never be copied elsewhere.  Bits of it might
be implemented in other languages (C or assembly), or at least other C++
standard versions.  A great deal of the C++ standard library would be
poor examples for modern C++ programming, precisely because it is /not/
modern C++ programming but has developed over the decades.

For the most part, consider the standard library source code of your
toolchain(s) as black boxes.  Occasionally it might be interesting to
peek inside for curiosity, but no more than that.

Very good advice,  but unfortunately no one will follow it.....remember hyram's law.