Re: simply question about syntatic sugar

[Sean Conner <sean@...>]

It was thus said that the Great Coda Highland once stated:
> 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:
> >
> >   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.)

  But I'm failing to see how that is different from structures.  I'm willing
to accept that not only do you accept the -> operator, you prefer the ->
operator as it makes a distinction you care about visble.  I have to accept
the -> operator because that's how C works (and I am NOT a C++ programer---I
can't stand the language myself) but would rather see it go as I don't see
it serving any real useful purpose.

  I surprised our C++ programmer around here [1] with this:

	struct foo  foo;
	struct foo *pf = &foo;

	pf[0].b = 1;	/* um ... wat? */

He knew this worked though:

	(*pf).b = 1;

> >   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.

  Looked at the right way, the same could be said of a struct---it's a
contiguously-allocated block of elements, but that each element can be of a
different type and the index is "named" not numbered.  But than again, I
come from a very strong assembly langauge background and can see that under
the hood, these two have the same layout:

	struct foo
	{
	  int a;
	  int b;
	  int c;
	} foo;

	int bar[3];

> 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.

  So what does C do right and what does C do wrong that I'm trying to
change?  

  -spc 

[1]	We're an odd shop.  90% of what we do is in Java and Javascript. The
	only C++ we have is in two projects, one of which is "C with
	classes" (not written by the mentioned programmer) and the other one
	is a bit more modern C++.