In reply to dave_59:
In reply to Tudor Timi:
Because the language is designed to execute what you wrote, not what you wanted to write. SystemVerilog may not be the strongest typed language out there, but it does have fixed set of rules for determining bit lengths. If we start changing the rules for every situation we think the user wants, the LRM would become exponentially bigger than it already is. And just look how sbellock misinterpreted what they thought bmorris wanted.
I’m not debating “executing what you wrote”. I’m debating the way sum() is defined:
sum() returns the sum of all the array elements or, if a with clause is specified, returns he sum of the values yielded by evaluating the expression for each array element.
The way people interpret a with syntax on first glance (without looking into the LRM) is that it sums all elements of the array for which the condition is true. I did this experiment with more of my colleagues who aren’t intimately acquainted with all LRM details and this was the exact answer I got. Forcing the current definition is the very reason such pitfalls exist, because it breaks the principle of least surprise.
Summing is one thing, applying a function on the values of an array is another thing. Summing the values resulted after applying a function on the values of an array is a cascade of the previous operations, which should be visible in the code. In e this would look like:
array.apply(<expression>).sum();