Yeah, yeah - I'm just throwing ideas - don't think I'll be bothering to
deal with you - if you don't find them useful - I won't bother arguing.

On Fri, Mar 18, 2022 at 4:49 PM Thiago Macieira via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Friday, 18 March 2022 05:00:52 PDT sasho648 via Std-Proposals wrote:
> > 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.
>
> If you want to change the behaviour of existing code, you must come up
> with a
> VERY good explanation why that is a good idea to silently change existing
> code
> and you haven't said more than "I suspect".
>
> But I actually don't think that there's any change possible... I don't
> think
> the expression above is valid. If ptrtomember is a PMF, then ptrtomember()
> is
> not a valid expression. Unless it's a class type that has a cast operator
> to
> PMF and a call operator?
>
> I don't know. Since you're the one proposing this, you're the one to
> investigate the possibilities, explain what might change, and the
> potential
> impact of such changes, weighing why changing is beneficial compared to
> just
> leaving things alone.
>
> > 1. Adding a way to symbolize (mangle) given symbol (for easier linker
> > access).
>
> WAY too complex for runtime. It basically requires a full C++ parser to
> exist
> in the C++ runtime library.
>
> > 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);
>
> new expressions require a type for a reason: they need to know the size
> and
> alignment of the type in question, and the expression returns a pointer to
> that type. If you're going to extract that from the type of the PMF, then
> you
> don't need the PMF to a constructor in the first place.
>
> If you want to type-erase the creation of an object, then you want to wrap
> around the PMF and we don't need new language syntax for this.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel DPG Cloud Engineering
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>