C2X Proposal, merge '.' and '->' C operators

C2X Proposal, merge '.' and '->' C operators

[J Decker]

Here's the gist of what I would propose...
https://gist.github.com/d3x0r/f496d0032476ed8b6f980f7ed31280da

In C, there are two operators . and -> used to access members of struct and
union types. These operators are specified such that they are always paired
in usage; for example, if the left hand expression is a pointer to a struct
or union, then the operator -> MUST be used. There is no occasion where .
and -> may be interchanged, given the existing specification.

It should be very evident to the compiler whether the token before '.' or
'->' is a pointer to a struct/union or a struct/union, and just build the
appropriate output.

The source modification for the compiler is very slight, even depending on
flag_c2x(that's not it's name).  It ends up changing a lot of existing
lines, just to change their indentation; but that shouldn't really count
against 'changed lines'.

I'm sure, after 4 score and some years ('78-19) that it must surely have
come up before?  Anyone able to point me to those existing proposals?

D

Re: C2X Proposal, merge '.' and '->' C operators

[J Decker]

This is a view of the patch/diff... This is really just +6 lines... ` if(
!flag_iso2xc) `{` `}` `attribute fallthrough`   `if(flag_iso2cx)` `return
ptr`

https://github.com/gcc-mirror/gcc/pull/41/commits/915bcffdea0aa4fead66c41830b66aa3db212307


While the compiler does compile itself, and a simple test case,
 successfully

```
#include <stdio.h>

struct s {
        int a, b;
};

void f( void ){
        struct s S;
        struct s *P = &S;
        P.a = 5; // 'wrong' operator
        P.b = 13;  // 'wrong' operator
        printf( "Output: %d %d\n", S->a, S->b );  // 'wrong' operators...
}

int main( void ) {
        f();
        return 0;
}
```

I haven't built the testsuite...


On Mon, Dec 16, 2019 at 5:51 AM J Decker <d3ck0r@gmail.com> wrote:

> Here's the gist of what I would propose...
> https://gist.github.com/d3x0r/f496d0032476ed8b6f980f7ed31280da
>
> In C, there are two operators . and -> used to access members of struct
> and union types. These operators are specified such that they are always
> paired in usage; for example, if the left hand expression is a pointer to a
> struct or union, then the operator -> MUST be used. There is no occasion
> where . and -> may be interchanged, given the existing specification.
>
> It should be very evident to the compiler whether the token before '.' or
> '->' is a pointer to a struct/union or a struct/union, and just build the
> appropriate output.
>
> The source modification for the compiler is very slight, even depending on
> flag_c2x(that's not it's name).  It ends up changing a lot of existing
> lines, just to change their indentation; but that shouldn't really count
> against 'changed lines'.
>
> I'm sure, after 4 score and some years ('78-19) that it must surely have
> come up before?  Anyone able to point me to those existing proposals?
>
> D
>

Re: C2X Proposal, merge '.' and '->' C operators

[Florian Weimer]

* J. Decker:

> Here's the gist of what I would propose...
> https://gist.github.com/d3x0r/f496d0032476ed8b6f980f7ed31280da
>
> In C, there are two operators . and -> used to access members of struct and
> union types. These operators are specified such that they are always paired
> in usage; for example, if the left hand expression is a pointer to a struct
> or union, then the operator -> MUST be used. There is no occasion where .
> and -> may be interchanged, given the existing specification.

This is incompatible with C++.  I don't think it's worthwhile to change
C in this way.

Thanks,
Florian

Re: C2X Proposal, merge '.' and '->' C operators

[J Decker]

On Tue, Dec 17, 2019 at 2:53 AM Florian Weimer <fweimer@redhat.com> wrote:

> * J. Decker:
>
> > Here's the gist of what I would propose...
> > https://gist.github.com/d3x0r/f496d0032476ed8b6f980f7ed31280da
> >
> > In C, there are two operators . and -> used to access members of struct
> and
> > union types. These operators are specified such that they are always
> paired
> > in usage; for example, if the left hand expression is a pointer to a
> struct
> > or union, then the operator -> MUST be used. There is no occasion where .
> > and -> may be interchanged, given the existing specification.
>
> This is incompatible with C++.  I don't think it's worthwhile to change
> C in this way.
>

ya, while I only just saw this, I thought shortly after posting that c++
compatibility might be an issue; and they have separate operators overrides
for -> and . (which V8 uses such that `Local<Object> lo;`  `lo.IsEmpty();`
and `lo->Get()`  are interchangeable.

However, if not specifically overridden it could be possible to make a
similar change there.   (and conversely not having the operator support the
C++ back port wouldn't be an issue).  It's still an error in the native
language context to use '.' on a pointer or '->' on a class/struct... and
the modification is really a patch to that error to just do the other
thing...



>
> Thanks,
> Florian
>
>

Re: C2X Proposal, merge '.' and '->' C operators

[J Decker]

On Fri, Dec 20, 2019 at 11:59 AM J Decker <d3ck0r@gmail.com> wrote:

>
>
> On Tue, Dec 17, 2019 at 2:53 AM Florian Weimer <fweimer@redhat.com> wrote:
>
>> * J. Decker:
>>
>> > Here's the gist of what I would propose...
>> > https://gist.github.com/d3x0r/f496d0032476ed8b6f980f7ed31280da
>> >
>> > In C, there are two operators . and -> used to access members of struct
>> and
>> > union types. These operators are specified such that they are always
>> paired
>> > in usage; for example, if the left hand expression is a pointer to a
>> struct
>> > or union, then the operator -> MUST be used. There is no occasion where
>> .
>> > and -> may be interchanged, given the existing specification.
>>
>> This is incompatible with C++.  I don't think it's worthwhile to change
>> C in this way.
>>
>
> ya, while I only just saw this, I thought shortly after posting that c++
> compatibility might be an issue; and they have separate operators overrides
> for -> and . (which V8 uses such that `Local<Object> lo;`  `lo.IsEmpty();`
> and `lo->Get()`  are interchangeable.
>
> However, if not specifically overridden it could be possible to make a
> similar change there.   (and conversely not having the operator support the
> C++ back port wouldn't be an issue).  It's still an error in the native
> language context to use '.' on a pointer or '->' on a class/struct... and
> the modification is really a patch to that error to just do the other
> thing...
>
and add -> on references?


>
>
>
>>
>> Thanks,
>> Florian
>>
>>

Re: C2X Proposal, merge '.' and '->' C operators

[J Decker]

On Fri, Dec 20, 2019 at 12:03 PM J Decker <d3ck0r@gmail.com> wrote:

>
>
> On Fri, Dec 20, 2019 at 11:59 AM J Decker <d3ck0r@gmail.com> wrote:
>
>>
>>
>> On Tue, Dec 17, 2019 at 2:53 AM Florian Weimer <fweimer@redhat.com>
>> wrote:
>>
>>> * J. Decker:
>>>
>>> > Here's the gist of what I would propose...
>>> > https://gist.github.com/d3x0r/f496d0032476ed8b6f980f7ed31280da
>>> >
>>> > In C, there are two operators . and -> used to access members of
>>> struct and
>>> > union types. These operators are specified such that they are always
>>> paired
>>> > in usage; for example, if the left hand expression is a pointer to a
>>> struct
>>> > or union, then the operator -> MUST be used. There is no occasion
>>> where .
>>> > and -> may be interchanged, given the existing specification.
>>>
>>> This is incompatible with C++.  I don't think it's worthwhile to change
>>> C in this way.
>>>
>>
>> ya, while I only just saw this, I thought shortly after posting that c++
>> compatibility might be an issue; and they have separate operators overrides
>> for -> and . (which V8 uses such that `Local<Object> lo;`  `lo.IsEmpty();`
>> and `lo->Get()`  are interchangeable.
>>
>> However, if not specifically overridden it could be possible to make a
>> similar change there.   (and conversely not having the operator support the
>> C++ back port wouldn't be an issue).  It's still an error in the native
>> language context to use '.' on a pointer or '->' on a class/struct... and
>> the modification is really a patch to that error to just do the other
>> thing...
>>
> and add -> on references?
>

My first patch was to make the . and -> interchangeable; it could be more
specifically to promote '.' to be either; with the intent to deprecate ->
(in like 2119).
This might simplify the scope of modification to C++; to just augment the
default '.' to behave as -> on a native pointer to a struct/class/union (
I'm not sure how the new safe_ptr templated things end up reacting, I'd
imagine they provide operator overloads, which would take precedence... )


>
>
>>
>>
>>
>>>
>>> Thanks,
>>> Florian
>>>
>>>

Re: C2X Proposal, merge '.' and '->' C operators

[Eric Gallager]

On 12/16/19, J Decker <d3ck0r@gmail.com> wrote:
> Here's the gist of what I would propose...
> https://gist.github.com/d3x0r/f496d0032476ed8b6f980f7ed31280da
>
> In C, there are two operators . and -> used to access members of struct and
> union types. These operators are specified such that they are always paired
> in usage; for example, if the left hand expression is a pointer to a struct
> or union, then the operator -> MUST be used. There is no occasion where .
> and -> may be interchanged, given the existing specification.
>
> It should be very evident to the compiler whether the token before '.' or
> '->' is a pointer to a struct/union or a struct/union, and just build the
> appropriate output.

I have mixed feelings on this proposal. On the one hand, when I was
first learning C, the difference between '.' and '->' was a major
source of confusion (as was understanding pointers in general). On the
other hand, now that I understand them a bit better, I find the
distinction to be helpful in reducing ambiguity and making code more
readable.

>
> The source modification for the compiler is very slight, even depending on
> flag_c2x(that's not it's name).  It ends up changing a lot of existing
> lines, just to change their indentation; but that shouldn't really count
> against 'changed lines'.
>
> I'm sure, after 4 score and some years ('78-19) that it must surely have
> come up before?  Anyone able to point me to those existing proposals?

I saw some Twitter threads and StackOverflow Q&As on the topic before;
I'm not really sure how to search to find them again though, given
that the punctuation involved is often treated as special
characters...

>
> D
>

Re: C2X Proposal, merge '.' and '->' C operators

[Ian Lance Taylor]

On Mon, Dec 16, 2019 at 5:52 AM J Decker <d3ck0r@gmail.com> wrote:
>
> Here's the gist of what I would propose...
> https://gist.github.com/d3x0r/f496d0032476ed8b6f980f7ed31280da
>
> In C, there are two operators . and -> used to access members of struct and
> union types. These operators are specified such that they are always paired
> in usage; for example, if the left hand expression is a pointer to a struct
> or union, then the operator -> MUST be used. There is no occasion where .
> and -> may be interchanged, given the existing specification.
>
> It should be very evident to the compiler whether the token before '.' or
> '->' is a pointer to a struct/union or a struct/union, and just build the
> appropriate output.
>
> The source modification for the compiler is very slight, even depending on
> flag_c2x(that's not it's name).  It ends up changing a lot of existing
> lines, just to change their indentation; but that shouldn't really count
> against 'changed lines'.
>
> I'm sure, after 4 score and some years ('78-19) that it must surely have
> come up before?  Anyone able to point me to those existing proposals?

For what it's worth, that is how Go works.  The '.' operator is used
for struct fields regardless of whether the left hand operand is a
struct or a pointer to a struct.

Ian

Re: C2X Proposal, merge '.' and '->' C operators

[Allan Sandfeld Jensen]

On Monday, 16 December 2019 14:51:38 CET J Decker wrote:
> Here's the gist of what I would propose...
> https://gist.github.com/d3x0r/f496d0032476ed8b6f980f7ed31280da
> 
> In C, there are two operators . and -> used to access members of struct and
> union types. These operators are specified such that they are always paired
> in usage; for example, if the left hand expression is a pointer to a struct
> or union, then the operator -> MUST be used. There is no occasion where .
> and -> may be interchanged, given the existing specification.
> 
> It should be very evident to the compiler whether the token before '.' or
> '->' is a pointer to a struct/union or a struct/union, and just build the
> appropriate output.
> 
> The source modification for the compiler is very slight, even depending on
> flag_c2x(that's not it's name).  It ends up changing a lot of existing
> lines, just to change their indentation; but that shouldn't really count
> against 'changed lines'.
> 
> I'm sure, after 4 score and some years ('78-19) that it must surely have
> come up before?  Anyone able to point me to those existing proposals?
> 
What if you operate on a pointer to a pointer to a struct? Should the same 
operator just magically dereference everything until it is a struct?

I disagree with this proposal because separate a thing and a pointer to a 
thing is fundamental to C/C++, and providing short-cuts that confuse the two 
is doing a disservice to anyone that needs to learn it.

Besides isn't this the wrong mailing list for this? 

'Allan

Re: C2X Proposal, merge '.' and '->' C operators

[Eric Botcazou]

> For what it's worth, that is how Go works.  The '.' operator is used
> for struct fields regardless of whether the left hand operand is a
> struct or a pointer to a struct.

Likewise in Ada.

-- 
Eric Botcazou

Re: C2X Proposal, merge '.' and '->' C operators

[J Decker]

On Sat, Dec 21, 2019 at 11:11 AM Allan Sandfeld Jensen <linux@carewolf.com>
wrote:

> On Monday, 16 December 2019 14:51:38 CET J Decker wrote:
> > Here's the gist of what I would propose...
> > https://gist.github.com/d3x0r/f496d0032476ed8b6f980f7ed31280da
> >
> > In C, there are two operators . and -> used to access members of struct
> and
> > union types. These operators are specified such that they are always
> paired
> > in usage; for example, if the left hand expression is a pointer to a
> struct
> > or union, then the operator -> MUST be used. There is no occasion where .
> > and -> may be interchanged, given the existing specification.
> >
> > It should be very evident to the compiler whether the token before '.' or
> > '->' is a pointer to a struct/union or a struct/union, and just build the
> > appropriate output.
> >
> > The source modification for the compiler is very slight, even depending
> on
> > flag_c2x(that's not it's name).  It ends up changing a lot of existing
> > lines, just to change their indentation; but that shouldn't really count
> > against 'changed lines'.
> >
> > I'm sure, after 4 score and some years ('78-19) that it must surely have
> > come up before?  Anyone able to point me to those existing proposals?
> >
> What if you operate on a pointer to a pointer to a struct? Should the same
> operator just magically dereference everything until it is a struct?
>
> how does pointer to a pointer to a struct work now?  Does it somehow
involve ppStruct->->a ?



> I disagree with this proposal because separate a thing and a pointer to a
> thing is fundamental to C/C++, and providing short-cuts that confuse the
> two
> is doing a disservice to anyone that needs to learn it.
>
> It's not to the assembly though.

To me, it's not a matter of it being a shorthand, but to make JS code more
portable back to C (and C++ compiled C).


> Besides isn't this the wrong mailing list for this?
>
> Probably?  I thought it a better starting point than the bug list?  Where
would you suggest I go?  It doesn't look like C standards, unlike
es-discuss for ecma script, I couldn't find a open forum to discuss such
things... or even a github group like... https://github.com/tc39/proposals

J


> 'Allan
>
>
>

Re: C2X Proposal, merge '.' and '->' C operators

[Tadeus Prastowo]

On Fri, Dec 27, 2019 at 7:23 AM J Decker <d3ck0r@gmail.com> wrote:
> would you suggest I go?  It doesn't look like C standards, unlike
> es-discuss for ecma script, I couldn't find a open forum to discuss such
> things... or even a github group like... https://github.com/tc39/proposals

You can table the proposal at the C++ standard discussion mailing
list: https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion

> J

-- 
Best regards,
Tadeus