Chris Torek <(E-Mail Removed)> writes:

>[snip]

>

> Finally, I would like to note that -- while it was never added to

> C99 -- there have been various proposals, over the years, to

> implement array assignment in C. I suspect that C1X or C2X (if

> these ever come about) may eventually do so -- and if so, I believe

> the "most natural" way to handle array assignment is to add a rule

> that says, in:

>

> a = b

>

> if "a" has type "array N of T", b is converted to a value of type

> "pointer to T" (and if it does not match a diagnostic is required);

> then the code acts much like a call of the form:

>

> memcpy(&a[0], b, sizeof a)

>

> except that the type of the result is "pointer to T" (rather than

> "pointer to void").
One would hope [0] that for an array assignment 'a = b' both

'a' and 'b' would have to be array expressions (and perhaps

even of identical numbers of elements). The chance of

memory being illegally accessed if b were allowed to be just

a pointer (which is implied, although not actually stated,

in Chris's comments), seems like too big a risk to allow

without needing an overt effort from the programmer. If a

pointer value were present for the right hand side, it could

always be cast to a suitable array type.

Also, to be consistent, the result of the array assignment

expression would still be of array type, so

a = b = c;

could be done.

[0] In the sense that at least one would hope because I

would, and I also would hope others would also.

> If this *were* added to C, the left side of a simple asignment

> operator would join the ranks of the "exceptions" for the

> array-to-pointer conversion rule.
Likewise the right hand side of an assignment expression where

the left hand side has array type.

> Of course, there are also "obvious" and "natural" (to me anyway)

> interpretations for:

>

> arr += arithmetic_type;

> arr -= arithmetic_type;

> arr++; /* same as arr += 1 */

> arr--; /* same as arr -= 1 */

> /* and so on for all arithmetic and logical operators */

>

> which involve replicated arithmetic applying the right-hand-side

> value (or implied 1, for ++ and --) to each element of the array,

> with the value of the expression as a whole again being "pointer

> to first element of array". (Some might object that this renders

> identical values for arr++ and ++arr, to which I say: "so what?" )
If extensions like these were going to be made, it seems

like it would be important to preserve the semantic

properties that C developers are used to for scalar

variables. In particular, for

a = b++;

a = ++b;

with both sides being arrays, it would be strange if the

two statements above had identical behavior. Certainly

it violates "The Law of Least Astonishment".

I don't know how useful (or non-useful) these kinds of

operators would be for array types, but certainly it seems

like there's a strong possibility of semantic confusion.

(Also programmer confusion, but who cares about that?

> All of these interpretations arise from one single central idea:

> naming an array always just names the entire array, but the "value"

> of an array (when a value is needed) is computed by finding a

> pointer to its first element. If a value is *not* needed, the

> array still names the entire array.
Perhaps this needs to be said differently. An expression

of array type remains an array when the context where it's

used needs an array; otherwise the array-type expression

is converted into a pointer to the array's first element,

as usual.

To be the most useful, it seems like array "assignment"

would also need to extend to passing of function parameters

and function results. There might be some difficulties

here. That's not to say that they couldn't be worked out,

but it's easy to imagine that there would be some unexpected

consequences.

> Again, this is not quite what the actual C standards (C89 and C99

> both) say, but it delivers the same result, in what I think is a

> simpler, yet ultimately more powerful, way.
I believe C would benefit from having arrays be more

completely integrated into the language, including at least

assignment and parameter/result passing. However, I suspect

the effort required for working out all the details for that

is more than many C experts might guess.