On Fri, Feb 28, 2020 at 5:34 AM Bjarne Stroustrup <bjarne_at_[hidden]>
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_at_[hidden]> 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_at_[hidden]> 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--
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__gist.github.com_d3x0r_f496d0032476ed8b6f980f7ed31280da-23the-2Dmeaning-2Dof-2D-2D-2Dand-2D-2D&d=DwMFaQ&c=u6LDEWzohnDQ01ySGnxMzg&r=-ypbxfA15hWRWp5mAlnCkA&m=r-p2sPYtgW9vx52cY3llBBeul0O7y8wIcs4dNMJTs-s&s=aS1qWqzUrPnjhstqWNjf-6xlWXnxaeOmcvoKpEEsvNQ&e=>
>> >
>> > 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
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_d3x0r_sack&d=DwMFaQ&c=u6LDEWzohnDQ01ySGnxMzg&r=-ypbxfA15hWRWp5mAlnCkA&m=r-p2sPYtgW9vx52cY3llBBeul0O7y8wIcs4dNMJTs-s&s=cj_DZuKqU0h8EMZ-cbdK1zFGeB5MXNE8gH2GRuwSDXg&e=> and
> some arbitrary source...
> https://github.com/d3x0r/SACK/blob/master/src/idlelib/idle.c
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_d3x0r_SACK_blob_master_src_idlelib_idle.c&d=DwMFaQ&c=u6LDEWzohnDQ01ySGnxMzg&r=-ypbxfA15hWRWp5mAlnCkA&m=r-p2sPYtgW9vx52cY3llBBeul0O7y8wIcs4dNMJTs-s&s=NfvK6o7zRd6CS7kuhTho1ll5pWV7u8pgpWd9EJKALi8&e=>
>
> 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
>
>