Hi Alex,

Constructors really aren't normal functions - you can't take pointers to
them, they're not really members, they're weird. I suggest making your own
`make<T>` function which delegates to a constructor.

G

On Fri, Mar 18, 2022 at 12:01 PM sasho648 via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Hello,
>
> I'm writing in regards the current situation with pointer to members.
>
> First issue and most confusing perhaps is the fact that dereferencing such
> pointers takes a primary expression (instead of unary). This reduces
> usability significantly. When you say:
>
> ptr.*.ptrtomember()
>
> I strongly suspect that you don't intend to dereference the result of a
> function call and even if that's the case (which will be a very obscure
> case) I suspect changing current behavior will still issue diagnostics if
> the code was valid before.
>
> I guess you are getting where I'm going to with this one - I suggest
> changing the syntax for pointer to member indirection operator to take a
> unary instead of primary expression with minimal breaking old code impact
> (I can only come to this conclusion given above thoughts).
>
> Another suggestion, kinda on the topic, would be:
>
> 1. Adding a way to symbolize (mangle) given symbol (for easier linker
> access).
>
> 2. Most significantly allowing pointer to constructor with syntax like:
>
> auto *ptrtocnstr = &Class::Class;
>
> auto *classinstance = new ptrtocnstr(cnstrarg0, cnstrarg1);
>
> auto *classplacement = new (classinstance) ptrtocnstr(cnstrarg0,
> cnstrarg1);
>
> The above changes would allow dynamically linking in system specific ways.
>
> Notes:
>
> For multiple constructors - the same way overloaded functions are
> determined, based on a cast.
>
> Thanks,
>
> Alexander Nikolov
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>