Date: Fri, 21 Feb 2020 10:12:21 +0200
On Thu, Feb 20, 2020 at 6:54 PM Thiago Macieira via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> On Saturday, 15 February 2020 21:14:19 PST J Decker via Std-Proposals
> wrote:
> > I can severely scope cut this, I do really only mean that, in the current
> > error condition where '.' is used and the left hand is a '*' pointer
> type,
> > that it can fallback to being like '->' and read the value of the pointer
> > instead of emitting an error.
> >
> > In the first cut, GCC C it ended up being just as easy to say '->' is the
> > same as '.' but that was incidental, not by strict definition.
>
> Before we go any further, we need WG14's opinion. The value for C++ alone
> is
> very close to zero or even negative if C doesn't adopt the same. C++ could
> be
> convinced to follow C for pointers but nowhere else if C adopts your
> proposal.
>
For C++ the value is indeed possibly negative, as this will literally
promote using raw pointers because their special properties.
we try to promote
something(const object& o);
instead of
something(const object* o);
For all cases where object is known to not be null (as far as `something`
is concerned).
This will throw a wrench in this practice.
Additionally, many people like the idea of observer_ptr, this will put
these in horrific disadvantage and will have to trade the improved safety
of observer_ptr to the convenience of the raw pointer.
This will be a painful decision to make for anyone.
EDIT: Now that I am rereading the idea. If this is allowed for non-raw
pointers as well (as a fallback), we are back at the issue that code can
change at later time by adding a method to the wrapper.
This will never be accepted.
> So please approach WG14 and propose that they adopt this. If they seem
> agreeable to considering it, WG21 can comment on whether it is for or
> against
> the feature. But if WG14 simply says it won't, the point is moot.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel System Software Products
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
std-proposals_at_[hidden]> wrote:
> On Saturday, 15 February 2020 21:14:19 PST J Decker via Std-Proposals
> wrote:
> > I can severely scope cut this, I do really only mean that, in the current
> > error condition where '.' is used and the left hand is a '*' pointer
> type,
> > that it can fallback to being like '->' and read the value of the pointer
> > instead of emitting an error.
> >
> > In the first cut, GCC C it ended up being just as easy to say '->' is the
> > same as '.' but that was incidental, not by strict definition.
>
> Before we go any further, we need WG14's opinion. The value for C++ alone
> is
> very close to zero or even negative if C doesn't adopt the same. C++ could
> be
> convinced to follow C for pointers but nowhere else if C adopts your
> proposal.
>
For C++ the value is indeed possibly negative, as this will literally
promote using raw pointers because their special properties.
we try to promote
something(const object& o);
instead of
something(const object* o);
For all cases where object is known to not be null (as far as `something`
is concerned).
This will throw a wrench in this practice.
Additionally, many people like the idea of observer_ptr, this will put
these in horrific disadvantage and will have to trade the improved safety
of observer_ptr to the convenience of the raw pointer.
This will be a painful decision to make for anyone.
EDIT: Now that I am rereading the idea. If this is allowed for non-raw
pointers as well (as a fallback), we are back at the issue that code can
change at later time by adding a method to the wrapper.
This will never be accepted.
> So please approach WG14 and propose that they adopt this. If they seem
> agreeable to considering it, WG21 can comment on whether it is for or
> against
> the feature. But if WG14 simply says it won't, the point is moot.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel System Software Products
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
Received on 2020-02-21 02:15:15