My initial point in response to your message was to point out that in C++, there are cases where making '.' behave as '->' does today breaks otherwise correct code and introduces ambiguity.

C++ users, contrary to C# or Java users, have the option of using objects directly or indirectly. In C# (excluding structs) and Java, all objects are accessed through indirect means. On the other hand, for a C++ programmer using a smart pointer such as unique_ptr<T>, the ability to distinguish the services exposed by that object (using '.') and those exposed by the pointee (using '->') carries meaning, and that distinction is not readily accessible in some other languages this proposal refers to.

Please also note that operator-> can be (and is sometimes) overloaded in C++ classes.

I think it would at least be necessary to address these (important) questions in the proposal, should it become something more formal.

Cheers!

Le ven. 28 févr. 2020 à 11:41, J Decker via Liaison <liaison@lists.isocpp.org> a écrit :


On Fri, Feb 28, 2020 at 5:34 AM Bjarne Stroustrup <bjarne@stroustrup.com> wrote:

How do you know that having . and -> roughly mean the same would be a benefit to the community at large?

For example, people assume that -> implies reference semantic and potential sharing, whereas . implies value semantic (except for non-const reference parameters) and lack of sharing. That could be more significant than the convenience of having just a single operator.

The burden of proof is on the proposer of a change.

It's hard to show how a change to C might play out; given 50 some years of history it's hardly even worth bothering to change. 
I'm understanding that it is less meaningful of a change to C++ other than as a compatibility should C accept such a thing.
It's encouraged practice to use newer smart pointer types, and I have a module for V8 which uses those all over, and certainly the use of '.' or '->' means different things, and it's still enforced by the compiler to use the right one.  I'm not entirely sure that there would even be much change to code developed in C++.

This is honestly a new idea only a few months old, as I was reflecting on 'why IS `((Something*)ptr).` an error' ?  Why are there two operators that aren't even interchangeable in context, and that there's only one choice to use.  I have spent a few years with C#, and recently ES6+(not even technically JS), and '.' seems easy enough to use, even when there's a mixture of C# structs(instance value types) and classes (reference, always referred by pointer), and it's not really a loss to inadvertently look in a value type, but then, the debugger reports 'null exception on this part of this expression' so you rarely even have to guess what it was.  I can't really demonstrate what sort of effect this would have on development; or even how it would change existing things.  (libz is still written with K&R style function declarations).  Certainly everything that has worked would still work.

Certainly, having already assigned a sort of meaning to them back in the 90's, I haven't ever really even questioned it until now.

It's my hypothesis that at the time this was developed, data driven programming (where the type of the data is [with] the data), and type inspection was not a consideration, but more, that one type needs to be another type ( float a = (float)213 ), and that C was more about coercion than inspection, so since a pointer to a thing and a thing definitely aren't the same, they have to be operated on differently; while conversely it can be said just look at the type of the operand and do the right thing.

On 2/28/2020 7:57 AM, J Decker via Liaison wrote:


On Thu, Feb 27, 2020 at 10:21 PM Uecker, Martin <Martin.Uecker@med.uni-goettingen.de> wrote:
Am Donnerstag, den 27.02.2020, 22:15 -0800 schrieb J Decker:
> On Thu, Feb 27, 2020 at 10:09 PM Uecker, Martin via Liaison <
> liaison@lists.isocpp.org> wrote:
>
> >
> > It is useful to have the information about
> > whether something is a pointer or not and the
> > difference between '.' and '->' makes it clear.
> >
>
> https://gist.github.com/d3x0r/f496d0032476ed8b6f980f7ed31280da#the-meaning-of---and--
>
> it reduces the points you have to check, but it's really not all that
> useful when dealing with a variety of languages.. '.' just becomes another
> place to check validity of the expression's values... So yes, it increases
> the potential things to check... but then, nothing stylistically prevents
> you from continuing to denote that.

If it not enforced by the language, the information
is unreliable. This is even worse than not having it.

I know, this is still really just me... https://github.com/d3x0r/sack and some arbitrary source... https://github.com/d3x0r/SACK/blob/master/src/idlelib/idle.c

there's a flags structure that is just instanced in another struct
check->flags.bDispatched = 1

that's used a few times, all other accesses are `->`
 
can you provide an example of where this information is useful?   Porting the above to c2x it wouldn't change how many things have to be looked at as suspect...
OR what is the information that distinct operators provides rather than using '.' everywhere (except, I suppose in C++ where you want to access an operator override on a pointer type.. )

class x {
   /* operaror->() ... */
};
class x *px;

px->x; (use operator?)



Best,
Martin
_______________________________________________
Liaison mailing list
Liaison@lists.isocpp.org
Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
Link to this post: http://lists.isocpp.org/liaison/2020/02/0054.php