What you clearly see as a flaw in the language, I see as fundamental to it
- a pointer is a pointer and a reference is a reference, and dereferencing
either through *ptr or ptr-> is the transition.

Adding a unification rule that has edge cases in the case of conflict is
generally worse, IMO, than not adding the rule at all. It means you
suddenly have to start being aware of the underlying type wrapping the
pointer (in the case of smart pointers and iterators, for example), and
that can get messy during refactoring and be a nuisance in template code.

And to achieve what? That's the biggest question, and I certainly can't
think of a good reason to do all that just to save one character.

On Thu, 5 Mar 2020, 03:15 J Decker via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

>
>
> On Wed, Mar 4, 2020 at 7:09 PM J Decker <d3ck0r_at_[hidden]> wrote:
>
>>
>>
>> On Wed, Mar 4, 2020 at 5:11 PM Andrey Semashev via Std-Proposals <
>> std-proposals_at_[hidden]> wrote:
>>
>>> On 2020-03-05 03:44, J Decker via Std-Proposals wrote:
>>> > Reformatted this to resemble standard proposal
>>> >
>>> > https://gist.github.com/d3x0r/f496d0032476ed8b6f980f7ed31280da
>>> > It fails to be ' The proposal may be in PDF, HTML, or plain text
>>> formats. '
>>> >
>>> > TL;DR
>>> >
>>> > C Standard section 6.5.2.3 Structure and union members
>>> >
>>> > add text in [ ]
>>> >
>>> > 1- The first operand of the . operator shall have a qualified or
>>> > unqualified structure or union type or [‘‘pointer to qualified or
>>> > unqualified structure’’ or ‘‘pointer to qualified or unqualified
>>> > union’’,] and the second operand shall name a member of that type.
>>> >
>>> > C++ Standard section 8.5.1.5 Class member access
>>> >
>>> > add: if the first expression of (dot) is a pointer [to an object],
>>> then
>>> > E1.E2 is converted to (*(E1)).E2 .
>>>
>>> I don't find your motivation compelling. The other languages you refer
>>> to (which ones? Java? JavaScript?) likely don't have the concept of a
>>> pointer and thus don't need a separate operator. You've been shown
>>> examples where having operators . and -> behave the same would break
>>> code. Special casing the proposal just for raw pointers is breaking
>>> consistency. So no, just no.
>>>
>>
>> I'm sorry I have seen 0 examples where they conflict in meaning and don't
>> continue to work the same way.
>> This maybe isn't as compelling for C++ which continues to have to use ->
>>
>> I have noted the complaint and will consider improving that.
>> rust, c#, go, kotlin, dart, typescript, ruby, python, swift (repurposes
>> -> as a type)....
>>
>> I don't know any that don't wait... https://cucumber.io/ this is a
>> testing framework
>>
>> >
>>
> (Sorry that image was cut, replace with text)
>
>> Feature: Guess the word
>>
>> # The first example has two steps
>> Scenario: Maker starts a game
>> When the Maker starts a game
>> Then the Maker waits for a Breaker to join
>>
>> # The second example has three steps
>> Scenario: Breaker joins a game
>> Given the Maker has started a game with the word "silky"
>> When the Breaker joins the Maker's game
>>
>> Then the Breaker must guess a word with 5 characters
>>
>>
>
>> C# has value type 'struct' which are values and are accessed with '.'
>> where a 'class' is always a reference type, and is always dereferencing a
>> pointer.
>>
>> J
>>
>> --
>>> 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
>