Re: simply question about syntatic sugar

[Coda Highland <chighland@...>]

On Sun, Jun 7, 2015 at 8:17 PM, Sean Conner <sean@conman.org> wrote:
> So, if C (or rather, the C compilers) can tell the difference between an
> array and a pointer to an array and still use the same syntax, then it
> should be just as easy (or the same) for C (or rather, the C compiler) to
> tell the difference between a struct and a pointer to a struct and use the
> same syntax.  The only reason we have what we have now is historical [1][2].

Do you really think it's safer to use identical syntax for member
access when the two types are otherwise handled entirely differently?
If you have two structs, assignment to one can't possibly modify the
other; if you have two pointers, they might well be pointers to the
same object. If you compare two structs, they might be distinct
objects but look identical; if you compare two pointers, they'll only
be the same if they refer to the same object. If you assign one struct
to another one, you have two structs with the same contents; if you
assign one pointer to another one, you leak memory and have two
handles to the same data.

It's not just historical reasons. The two types are FUNDAMENTALLY
distinct, and the syntax should reflect that, even though the compiler
clearly knows how to dereference both.

On Sun, Jun 7, 2015 at 2:45 PM, Nagaev Boris <bnagaev@gmail.com> wrote:
> If C used "." to dereference a pointer and get a field from a
> structure, it would be incompatible with C++. C++ allows overriding
> "->", which allows smart pointers and iterators. C++ compiler would
> not tell the difference between smart pointer's methods and methods of
> pointed value. It is impossible to override "." in C++.
>
>
>
> C would be better and cleaner language if array type removed in favor
> of pointers.
>
>    void bar(int[] foo);    -->    void bar(int* foo);
>
> A variable created by static array declaration would be a pointer.
>
> sizeof(array) would not work, well and good -- it is too easy to make
> an error using this feature.

So wait. You're telling me you want to take the most dangerous feature
in C... and make it MORE dangerous?!

/s/ Adam