Just thinking, but could I get away with the claim that:
Given type array;
array is a type *const to the first element of the array? I would think this would address any potential l-value problems.
I'm afraid you couldn't get away with that claim either, eg,
The type, int, is different to int* const - While int may implicitly cast to int* const without problems, the opposite does not hold true
void foo(int (&arr) [N] )
foo( bar ); // ok
int* const blah = bar;
// foo( blah ) ; //error
On the other hand, a claim you might be able to get away with, could be that given a declaration, T array; , that the type of 'array' is equivalent to T(&) (Perhaps someone else would like to support or dismiss that claim)
Originally Posted by Bench82
I never claimed the opposite. If a then b does not imply if b then a.
That wasn't quite what I was getting at though. The main point, is that type information is the overriding factor. An array may implicitly cast to a pointer because it loses type information in the process, regarding the number of elements in the array. (information that a pointer isn't equipped to hold)
Originally Posted by AverageSoftware
As a result, the pointer contains only the information regarding the first element. This is why an array type is not a pointer type.
You're just using the wrong terminology.
array is an l-value denoting the array.
&array is an r-value denoting the address of the first element of the array.
Whenever array is converted to an r-value, the resulting r-value is the same as &array.
But value alone is an ambiguous term.
array == &array is only true because the first term has been implicitly converted to an r-value.