Re: [sv-bc] 8.13.1 Array assignment patterns

Bresticker, Shalom wrote:
> Question 1:
> 
> In 8.13.1, at the bottom of page 180, it says, 
> "For more arrays of structures, it is useful to specify one or more matching type keys."
> 
> What is the meaning of the first "more" in this sentence?

I don't know.  I also have trouble with the word "useful".  Perhaps we can strike
the whole sentence as it only seems to be a sales pitch.


> Question 2: 
> 
> 8.13.1 says,
> "The default:value applies to elements or subarrays that are not matched by either index or type key. If the type of the element or subarray is a simple bit vector type, matches the self-determined type of the value, or is not an array or structure type, then the value is evaluated in the context of each assignment to an element or subarray by the default and must be castable to the type of the element or subarray; otherwise, an error is generated. For unmatched subarrays, the type and default specifiers are applied recursively according to the rules in this clause to each of its elements or subarrays. For unmatched structure elements, the type and default keys are applied to the element according to the rules for structures."
> 
> Although I think I understand the intent of this paragraph, I find the wording very difficult.
> 
> It seems to say the following (2nd sentence, my additions in uppercase):
> 
> "If the type of the element or subarray is a simple bit vector type OR IF THE TYPE matches the self-determined type of the value OR IF THE TYPE is not an array or structure type, then the value is evaluated in the context of each assignment to an element or subarray by the default and must be castable to the type of the element or subarray; otherwise, IF THE TYPE DOES NOT MEET ONE OF THESE 3 CONDITIONS, an error is generated."
> 
> It seems to say that either one of the 3 conditions is met or an error is generated.

The second sentence here runs-on too long for its own good.
Your parse is accurate, and shows that this text does not capture
the design intent.

One problem is the "; otherwise" conjunction, which should NOT be
offering an alternative to the three-part conditional.  It only
describes what happens when a "default:value" clause matches some
element (or subarray) under one of those three conditions but
whose value fails to be castable to the element (subarray) type.
In such a case, an error issues.  The "match" succeeds - no further
recursion happens - but the assignment operation fails!

The larger problem is that it has proven hard to express the
precedence order between the different clauses AND how the
recursion (of "type:" and "default:" clauses) applies to all
unmatched elements.

I'd prefer rewriting these sentences; they should specify:
   - When defaults are considered
   - What it means for a default to "match"
   - What happens on a match
   - What happens to things that didn't match.

"Elements or subarrays that do not match any "index:" or "type:"
  specifier become candidates to match a "default:value" specifier."


"An element or subarray matches a given "default:value" specifier if it:
   - has a simple bit vector type,
   - has a type which matches the self-determined type of the value, OR
   - does not have an array or structure type."


"Each element or subarray that matches a "default:value" specifier
  becomes (the left hand side of) an assignment context in which the
  (right hand side) value is actually evaluated.  This value must be castable
  to the type of the element or subarray; otherwise, an error is generated."


"Subarrays that do not match any "index:", "type:", or "default:" specifier
  are assigned a new pattern consisting of just the "type:" and "default:"
  specifiers of the current pattern by recursively applying the rules
  of this clause to each unmatched subarray."


"Elements with a structure type that do not match any "index:", "type:", or
  "default:" specifier are assigned a new pattern consisting of just the
  "type:" and "default:" specifiers of the current pattern by recursively
  applying the rules for structure-valued assignment patterns (see 8.13.2)."


An analogous edit for 8.13.2 should be pretty obvious.

This is actually wordier than the C code needed to implement it.
But we were too aggressive compressing it into a simple paragraph.
So it's probably safer to lay it all out in tedious prose.

As you can see, this longer version uses all of the clauses from
the existing text and it captures the discussions we had in sv-bc
committee during the several meetings devoted to resolving these
issues.  The key resolutions were: to consider the self-determined
typee of the default specifiers, to use multiple context-determined
evaluations of the default value expressions, to recurse into packed
structure types, and to permit assignment coercions of scalar
and simple bit vector types.  It is not my intent to reconsider
those choices - recall that they are rather intricately interrelated.

Hope this helps, and sorry for my role in any confusion,

Greg Jaxon





> 
> Then it says,
> "For unmatched subarrays, ... For unmatched structure elements, ..."
> 
> These seem to talk about cases where none of the 3 conditions is met. But we said that an error is generated in that case.
> 
> Even if I am misreading the text, it means that the text is at best unclear.
> 
> Please clarify.
> 
> 8.13.2 has a similar problem.
> 
> 
> Thanks,
> Shalom