On Thu, Feb 20, 2020 at 6:54 PM Thiago Macieira via Std-Proposals <std-proposals@lists.isocpp.org> 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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals