On Thu, Feb 27, 2020 at 9:50 AM J Decker <d3ck0r_at_[hidden]> wrote:

>
>
> On Thu, Feb 27, 2020 at 7:54 AM Patrice Roy via Liaison <
> liaison_at_[hidden]> 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_at_[hidden]> 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)
>>> https://gist.github.com/d3x0r/f496d0032476ed8b6f980f7ed31280da
>>>
>>> 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_at_[hidden]
>>> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
>>> Searchable archives: http://lists.isocpp.org/liaison/2020/02/index.php
>>>
>> _______________________________________________
>> Liaison mailing list
>> Liaison_at_[hidden]
>> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
>> Link to this post: http://lists.isocpp.org/liaison/2020/02/0044.php
>>
>