Date: Fri, 18 Mar 2022 20:27:45 +0100
On 18/03/2022 19.47, sasho648 via Std-Proposals wrote:
> 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.
Throwing ideas around in this forum as a first step is good,
but if you intend for your ideas to go into a future C++
standard, you'd need to create a convincing proposal:
https://isocpp.org/std/submit-a-proposal
Thanks,
Jens
> On Fri, Mar 18, 2022 at 4:49 PM Thiago Macieira via Std-Proposals <std-proposals_at_[hidden] <mailto: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 <http://macieira.info> - thiago (AT) kde.org <http://kde.org>
> Software Architect - Intel DPG Cloud Engineering
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]>
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals <https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals>
>
>
> 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.
Throwing ideas around in this forum as a first step is good,
but if you intend for your ideas to go into a future C++
standard, you'd need to create a convincing proposal:
https://isocpp.org/std/submit-a-proposal
Thanks,
Jens
> On Fri, Mar 18, 2022 at 4:49 PM Thiago Macieira via Std-Proposals <std-proposals_at_[hidden] <mailto: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 <http://macieira.info> - thiago (AT) kde.org <http://kde.org>
> Software Architect - Intel DPG Cloud Engineering
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]>
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals <https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals>
>
>
Received on 2022-03-18 19:27:49