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.


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.

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
>