On Sun, Feb 2, 2025 at 2:57 AM Robin Savonen Söderholm <
robinsavonensoderholm_at_[hidden]> wrote:

> Not sure I entirely follow your train of thought about the smart pointers..
>

No change to smart pointers.
for simple types there's also no change, since -> and . are both
invalid... int *f; f.? f->? (? is like what would even go here?
.type? no that's typeof )

In the paper I was exploring ideas - depending on how the patch is
implemented, it could end up resolving multiple levels of pointers are
`*(p+0).` recursively struct foo { int a; } ****p; then it could be that
`p.a = 0;` becomes valid... but if that's actually a pointer to an array
then the access would be more like p[0][5][3][0].a ; and it would only
apply to the 0'th element in each pointer to multiple elements in a row;
while cute, I don't think this should be implemented; and -> or .
should just peel back one layer.

union, class, struct instances(objects/allocated space of such types), and
the access to their members through raw pointers is the only behavior that
changes. But that's not really the way I look at it; it's really '.' that
changes to become do a single function 'get a value from an object.' .
However that is done, is accomplished by the compiler - much like `3L * 5f`.

In C++ there isn't even an `operator->` and `operator.` (not sure what the
arguments would be - the text string that was asked for?) then I'd have
have to also say 'any overridden . operator isn't changed' since someone
assigned some other meaning for it... (much like they could for % or () or
- )

---
Regarding code migrations; not necessarily in this message... but say you
are writing C-ish code, and you have a large struct with lots of members;
and maybe you've discovered that only a subset of those values are commonly
used and should really be in another area.  One might first start by
grouping the variables in the structure into just being an instance in the
struct like it was, and then merely change the type, and allocate some
space for it, and all of the code referencing it wouldn't change.
And even so, it would only end up showing up in common headers; and then
only those that chose to be only standard XYZ....
But certainly C++ has added features that make even using C++17 or less
impossible with some code.   Zlib was still written with K&R function
declarations until a few years ago (if that long ago)... there's certainly
something about the huge legacy that even trying to use '.' with portable
code would even be impractical...  I'm sure there's still reluctance to use
c99 initializer tags   `{ .whatever = 3, ... }`   since MS didn't get C99
working until 2015.
(and yes - compatibility for interface headers which may have code is a
compatiiblity point to care about; I ruminated on forgetting that for a
while )
> Are you suggesting that smart pointers should forward operator'.' to
> whatever they are pointing to? Then how would we distinguish e.g. a
> 'pointer.reset()' from a potential 'pointer->reset()' if whatever it is
> pointing to also happens to provide a method 'reset'? Or any other member
> methods of a smart pointer. Similar arguments are made for optional,
> expected...
> If you are suggesting that smart pointers should keep their operator->()
> then they are not so much pointers as more "pointer like" because they no
> longer support the same API.
> I also have a "hygience" argument that raw pointers should not be the
> "go-to" when dealing with references (that would be, well, references) and
> definitely not resource management. They should mainly be used when you
> need to re-point a reference for various reasons, and in those situations I
> second what has been said before: the different access syntax makes it
> perfectly clear that something here might need to be checked before the
> access, even when not viewing the code from an IDE.
>
> My 2c.
>
> // Robin
>
> On Sun, Feb 2, 2025, 10:39 J Decker via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>>
>>
>> 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
>>>>
>>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>