[sv-ec] Contradictions on associative arrays

The text that was rewritten and moved into 5.10.8 by Mantis item 976
seems to contradict other text.  It allows the index argument to be
merely assignment compatible with the array index type.  The function
prototypes in 5.10.4, 5.10.5, 5.10.6 and 5.10.7 declare the argument
to be a ref argument, which requires equivalent types.  The description
of truncation becomes unnecessary if the types must be equivalent.
The entire section should be removed if these are ref arguments.

On the other hand, if we accept 5.10.8 as allowing mere assignment
compatibility and possibly performing truncation on integral types,
then the function prototypes should not declare ref arguments.  They
should declare inout arguments instead.

If these are changed to inout arguments, then this affects Mantis
item 1457.  Not allowing wildcard indexes for these method calls made
sense with ref arguments.  No type could match a wildcard index.  But
if the arguments are inout arguments, then wildcard indexes could be
allowed, with the truncation rules described.

In fact, this issue with wildcard indexes is the only reason I can
see for allowing anything but equivalent types.  For any specific
type, I don't see any advantage to allowing any other type to be used.
The truncation could lead to infinite loops in the user code if the
return value is not checked, and provides no useful added functionality.
If someone really wanted to assign the index to a different type, they
can do it themself after the method returns.  

With wildcard indexes, allowing assignment compatibility and truncation
would let these methods be used, though with the same danger.  If this is 
considered worth the danger, it might be worthwhile to make these arguments
inout only with a wildcard index, and ref otherwise.

Steven Sharp
sharp@cadence.com


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.