Re: simply question about syntatic sugar

[Coda Highland <chighland@...>]

On Sun, Jun 7, 2015 at 10:50 PM, Sean Conner <sean@conman.org> wrote:
> It was thus said that the Great Coda Highland once stated:
>> 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?
>
>   You're talking about arrays, right?  Because it's deadly when you do:
>
> file1.h
>
>         extern int *foo;
>
> file1.c
>
>         int foo[256];
>
> even though at the source level, you can use the same syntax, even though
> this creates a huge mess rather quickly ... oh wait!  You're talking about
> structs!  Silly me.

You can do stupid things in any language.

>> 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.
>
>   C is trying to solve that problem with restrict [1].  And that sill leaves
> the same issue with arrays, with identical syntax:
>
>         foo[4] = 4;
>         pfoo[4] = 5;
>
>         /* is foo[4] still 4?  */
>
> So I don't really think the argument along these lines is constructive.

That's not an accurate analogy with my argument. As I described with
C++ references, the ABILITY to alias is important, necessary, and in
certain circumstances desirable; restrict is there for the cases where
you specifically know you DON'T want that.

In your example, you KNOW pfoo is a pointer, and therefore you know
that it could possibly (and perhaps intentionally) alias foo. But my
argument was about two struct, or two pointers, not about a struct and
a pointer. To be analogous, you would have to compare the behavior of
two arrays:

foo[4] = 4;
bar[4] = 5;

And in this case, assuming that at least one of them is a local
variable, you CAN be certain that foo[4] is still 4 after this. (If
they're both function parameters, then that's where restrict is
necessary.)

>   So are arrays and pointers.  But they aren't treated differently
> syntactically.

I could argue that they're NOT fundamentally different in C, that an
array is just a specific kind of pointer that happens to refer to a
contiguously-allocated block of elements instead of a single item.

But that's actually not necessary. No one ever claimed C was the
pinnacle of well-designed languages. There are certainly things that C
could do better. But don't suggest that you change something that C is
doing something right just for consistency with something else that it
does wrong.

If you were to make a change, it should be to make arrays NOT decay to
pointers, to make them a fundamental data type of their own, like C++
did by introducing container classes... not to remove arrays from the
language.

> [1]     Although C++ compilers don't seem to respect restrict.

restrict is a C99 thing. None of C++03, C++11, or C++14 include it (or
VLAs, another C99 feature, which is downgraded to "optional" in C11
anyway). C++ needs it less because you can use containers to mostly
avoid the problem, but adding it to C++ would be troublesome because
of the difficulty of determining exactly WHAT would be guaranteed to
be distinct and what might still be aliased. (Do two classes that
contain pointer members to aliased data violate restrict or not?)

/s/ Adam