On Thu, Feb 27, 2020 at 9:50 AM J Decker <d3ck0r@gmail.com> wrote:


On Thu, Feb 27, 2020 at 7:54 AM Patrice Roy via Liaison <liaison@lists.isocpp.org> wrote:
Hello Jim.

With your proposal, how would you make sense of the following?

#include <memory>
struct X {
   int get() const { return 3; }
};
void f() {
   auto p = std::make_unique<X>();
   p.get(); // X::get() or std::unique_ptr<X>::get()?
}

that behavior does not generate an error; and it was mentioned all the other `_ptr` types (unique_ptr) being part of that.
My primary use case is back-porting changes to code that was ported from C to JS.  And C that compiled as C++, and taking those changes and back porting to the original C...
In this case '.' generates a compilation error, and there is no alternative meaning to '.' currently that would apply.


What I mean is AFAICT (can tell), _ptr types are in their base form a structure declaration, and the '.' operator is working like it always did.  They they have the ability to specify an operation for `operator->` which allows them to return their pointer content.  This means there really isn't a conflict, because they're already just an instance of a class/struct/union.

It is possible that there was instead a modification internally so that the '.' operator is instead overloaded for those, but I don't think so, since they are the declaration of an instance of a pointer.
 



Le jeu. 27 févr. 2020 à 09:41, J Decker via Liaison <liaison@lists.isocpp.org> a écrit :
I could feature-request this for all known compilers, and that's what this is really an attempt at.

 
this is the gist of it (more of a detailed explanation)

the TL;DR is really the title.

I'd like to know how a community contribution might be submitted for approval for the future c2x.

I've been to C++ proposals list, and they have provided me with some feedback, and suggested maybe this is an operable method(?).

Jim

http://github.com/d3x0r (it's pronounced Decker)
 
_______________________________________________
Liaison mailing list
Liaison@lists.isocpp.org
Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
Searchable archives: http://lists.isocpp.org/liaison/2020/02/index.php
_______________________________________________
Liaison mailing list
Liaison@lists.isocpp.org
Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
Link to this post: http://lists.isocpp.org/liaison/2020/02/0044.php