On Sun, Feb 2, 2025 at 1:04 AM Jonathan Wakely <cxx_at_[hidden]> wrote:

>
>
> On Sun, 2 Feb 2025, 07:00 J Decker via Std-Proposals, <
> std-proposals_at_[hidden]> wrote:
>
>> The most notable complaint is loss of information about the
>> preceding variable's type.... which can be handled with variable name
>> notation like 'pBlah' vs 'oBlah'...
>>
>
> No, Hungarian notation is not an acceptable alternative.
>
> The second complaint is the conflict with smart pointers...
>> I wasn't quick enough at the time to say 'well if you're pushing use of
>> smart pointers, and
>>
>
> What does "pushing use of smart pointers" mean? Sounds like opinionated
> nonsense.
>

I feel like there's sections of the minutes missing; it was said something
like 'we are suggesting use of smart points anyway' with pushing being my
paraphrase for the same idea... it might have even been pushing; but
there's only one instance of 'smart' in the minutes, and I'm certain that
word was said more than once.


>
>
> this doesn't affect smart pointers, since '.' already has a well defined
>> behavior... it's a nothing-burger for you anyway; and would just be part of
>> compatibility with C' (extending '.' to look at the left type).
>>
>
> I'm not sure what you're trying to say. If -> is not used for pointers,
> but is still used for smart pointers and std::optional etc then you haven't
> really simplified anything. Just created inconsistency where there was
> consistency before.
>

I understand this viewpoint; but in having accepted '.' (in a post '.'
derefercing pointer view) it is a consistent behavior to access a member of
an object rather than 2 methods. Just because idomatic C++ doesn't get the
same benefit of 'consistency' now that you mention these things, seems
unfair to keep others from having it... but then who besides me maintains C
that is also C++ compilable? Do we/should we really even care about
compatibility?


>
> The motivation for this change is very weak.
>
>
>
>> there is typically one extra memory lookup when following '.'.
>>
>> Legacy behavior can be enforced by a linter.... but I've been considering
>> adding it as a modification to the existing error to indicate that another
>> option may be used to enable this behavior - then at least it's an opt-in;
>> though that's a bit more work to implement than just the few lines in the
>> right places...
>>
>> Jim
>>
>> On Sat, Feb 1, 2025 at 3:53 AM Sebastian Wittmeier via Std-Proposals <
>> std-proposals_at_[hidden]> wrote:
>>
>>> Because it is an active thread, I want to mention that there has been an
>>> update by SG22 (the C/C++ Liaison), now it is back in EWGI's court:
>>>
>>>
>>>
>>> "Seen by SG22. Feedback to the author given. We do not think this paper
>>> is a good candidate for inclusion in C++. See minutes for details of
>>> discussion."
>>>
>>> https://github.com/cplusplus/papers/issues/868
>>>
>>>
>>>
>>>
>>>
>>>
>>> -----Ursprüngliche Nachricht-----
>>> *Von:* Filip via Std-Proposals <std-proposals_at_[hidden]>
>>> *Gesendet:* Fr 31.01.2025 11:33
>>> *Betreff:* Re: [std-proposals] Possible deprecation of -> operator
>>> *An:* std-proposals_at_[hidden];
>>> *CC:* Filip <fph2137_at_[hidden]>;
>>> Hi thanks for that link, I will try and help with this.
>>>
>>> Cheers, Filip
>>>
>>> Wiadomość napisana przez Sebastian Wittmeier via Std-Proposals <
>>> std-proposals_at_[hidden]> w dniu 31 sty 2025, o godz. 11:27:
>>>
>>> 
>>>
>>> Hi Filip,
>>>
>>>
>>>
>>> I think it is a bit more involved.
>>>
>>>
>>>
>>> There is an active proposal going into that direction:
>>>
>>>
>>>
>>> https://github.com/cplusplus/papers/issues/868
>>>
>>> P2142 Allow '.' operator to work on pointers
>>>
>>>
>>>
>>> Perhaps you can cooperate?
>>>
>>>
>>>
>>>
>>> -----Ursprüngliche Nachricht-----
>>> *Von:* Filip via Std-Proposals <std-proposals_at_[hidden]>
>>> *Gesendet:* Fr 31.01.2025 11:23
>>> *Betreff:* [std-proposals] Possible deprecation of -> operator
>>> *An:* std-proposals_at_[hidden];
>>> *CC:* Filip <fph2137_at_[hidden]>;
>>> Hi everyone,
>>>
>>> I’m wondering about the possibility of removal or deprecation of ->
>>> operator in favor of automatic dereference by ‘.’
>>>
>>> If I remember correctly in tcc, compiler has a single if to check if
>>> they are used correctly and could automatically use the correct operation.
>>>
>>> Are there any good reasons to keep that syntax?
>>> In my experience it’s just an annoying part of early c that is
>>> maintained.
>>>
>>> Cheers,
>>> Filip
>>>
>>> Cheers, Filip
>>>
>>> -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>
>>>
>>> --
>>> Std-Proposals mailing list
>>> Std-Proposals_at_[hidden]
>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>
>>> --
>>> Std-Proposals mailing list
>>> Std-Proposals_at_[hidden]
>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>
>>>
>>> --
>>> Std-Proposals mailing list
>>> Std-Proposals_at_[hidden]
>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>