Date: Fri, 18 Mar 2022 07:49:31 -0700
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.
> 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
Received on 2022-03-18 14:49:33