RE: [sv-bc] 5.15.3 Array reduction methods - result type

I understand the reasoning, but it is not the Right Thing to do here.
It is not what users will want.

You say that in some cases, e.g., a big array of big integers, even 32
bits might not be enough for the return value. That is true, but that
case will be much rarer than the current definition. And an explicit
note in the LRM could warn about that rare case.

I propose that the return value of sum() and product() should be 32-bit
integers for integral type array elements.

A question about the current definition is whether the return type is
self-determined or context-determined. If I write (array.sum() + 0),
does that turn sum() into 32 bits before its calculation and prevent the
loss of bits, or is sum() first calculated according to the element type
and only afterwards bit-extended?

My intuition expected the 2nd case, meaning that I don't even have a way
to prevent or workaround the overflow. But apparently at least one
simulator does it the first way.


> > Suppose I have an array of type bit. It would appear that sum() will
> > give me a result of 1-bit width, which is not what I want. This is
at
> > the least going to surprise users and make them unhappy...
> 
> If you're familiar with the verilog rules for expression
> sizing, it won't surprise you to find that adding two bits
> gives you one bit!
> 
> But what else can you expect?  Even with an array of integers,
> you might want the return value to be more than 32 bits wide
> to accomodate the sum.
> 
> Paul
 
Thanks,
Shalom