It's easy enough if you extend the type system to include
lvalueness.

T Type T.
&T A T lvalue. & can only appear as the outermost.
*T A T pointer.

(implied) &T --> T Load operator.
= &T=T --> T Assign operator.
& &T --> *T Address operator.
* *T --> &T Dereference operator.
(...) *T(...) --> T Derefence and call operator.
[...] *T[e] --> &T Array index.

P u; Simple declaration of identifier u with type &P.
Q *v; Declare v with type &*Q.
R w[]; Declare w with type *R.

(&P)u = (T)e; Coerce e to (P) and assign.
(&T)e = (&P)u; Load u; coerce to T, assign to e.
(&P)u[...] [...] not defined for &P or P.
&(&P)u --> (*P) Address operator.
*(&P)u * not defined for &P or P.

(&*Q)v = (T)e; Coerce e to (*Q) and assign.
(&T)e = (&*Q)v; Load v; coerce to T, assign to e.
(&*Q)v[...] --> &Q Load v to (*Q); apply array index.
&(&*Q)v --> (**Q) Address operator.
*(&*Q)v --> (&Q) Load v to (*Q) and deref.

(*R)w = (T)e; = not defined for *R.
(&T)e = (*Q)w; Coerce to T, assign to e.
(*R)w[...] --> &R Apply array index.
&(*R)w & not defined for *R. By special
dispensation the & is ignored and
returns (*R)w.
*(*R)w --> (&R) Apply deref.

--
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @
'I desire mercy, not sacrifice.' /|\
Discordia: not just a religion but also a parody. This post / \
I am an Andrea Doria sockpuppet. insults Islam. Mohammed

On 7/17/2021 1:20 PM, Chris M. Thomasson wrote:
> On 7/15/2021 1:21 PM, Andrey Tarasevich wrote:
>> 6.3.2/1 says that
>>
>>    1 [...] A modifiable lvalue is an lvalue that does not have array
>> type, [...]
>>
>> Based on that, arrays are non-modifiable lvalues. We all know what it
>> actually means. But is there any context in the standard in which this
>> non-modifiability of array lvalues would actually _matter_, would
>> actually interact with some other standard requirement?
>>
>> One thing that comes to mind is a constraint on assignment operators
>> (6.5.16/2)
>>
>>    2 An assignment operator shall have a modifiable lvalue as its left
>> operand.
>>
>> So, one can combine 6.3.2/1 and 6.5.16/2 and conclude that one can't
>> assign to arrays. But I believe that constraints are intended/supposed
>> to be applied after automatic implicit conversions. And since LHS of
>> assignment is not one of the contexts excluded from array type decay,
>> said decay is already sufficient to prevent assignment to arrays.
>>
>> Am I right here? Is the constraint of 6.5.16/2 supposed to be applied
>> before automatic implicit conversions or after them?
>>
>> And if the answer is "after", then is there any other context in C
>> standard where non-modifiability of array lvalues would make a
>> difference?
>>
>
> I must be missing something. Fwiw, sometimes I wrap fixed arrays in
> structs just to be able to copy them via assignment:
>

And? In my question I'm talking about behavior of expressions of array
type and how language constraints are checked against such expressions.

Copying arrays wrapped in structs has nothing to do with that topic. And
yes, you can copyin arrays wrapped in structs.

--
Best regards,
Andrey Tarasevich

On 7/19/2021 2:44 PM, Andrey Tarasevich wrote:
> On 7/17/2021 1:20 PM, Chris M. Thomasson wrote:
>> On 7/15/2021 1:21 PM, Andrey Tarasevich wrote:
>>> 6.3.2/1 says that
>>>
>>>    1 [...] A modifiable lvalue is an lvalue that does not have array
>>> type, [...]
>>>
>>> Based on that, arrays are non-modifiable lvalues. We all know what it
>>> actually means. But is there any context in the standard in which
>>> this non-modifiability of array lvalues would actually _matter_,
>>> would actually interact with some other standard requirement?
>>>
>>> One thing that comes to mind is a constraint on assignment operators
>>> (6.5.16/2)
>>>
>>>    2 An assignment operator shall have a modifiable lvalue as its
>>> left operand.
>>>
>>> So, one can combine 6.3.2/1 and 6.5.16/2 and conclude that one can't
>>> assign to arrays. But I believe that constraints are
>>> intended/supposed to be applied after automatic implicit conversions.
>>> And since LHS of assignment is not one of the contexts excluded from
>>> array type decay, said decay is already sufficient to prevent
>>> assignment to arrays.
>>>
>>> Am I right here? Is the constraint of 6.5.16/2 supposed to be applied
>>> before automatic implicit conversions or after them?
>>>
>>> And if the answer is "after", then is there any other context in C
>>> standard where non-modifiability of array lvalues would make a
>>> difference?
>>>
>>
>> I must be missing something. Fwiw, sometimes I wrap fixed arrays in
>> structs just to be able to copy them via assignment:
>>
>
> And? In my question I'm talking about behavior of expressions of array
> type and how language constraints are checked against such expressions.
>
> Copying arrays wrapped in structs has nothing to do with that topic. And
> yes, you can copyin arrays wrapped in structs.
>

I missed your point. Sorry. ;^/