RE: [sv-bc] Is dynamic variable written in continuous assignment

The phrase "-class properties and dynamically sized variables-" is
parenthetical and should be removed.

 

My philosophy is that simpler is better, re-use is better. The fewer
rules there are, the easier it is for users and implementers to
understand the language. If we have existing rules for writes to out of
bounds array elements, why do we need special rules for out of bounds
NBA writes? 

 

When do we need additional rules?

 

1.                          If the semantics are too ambiguous or
difficult to define without them. Until I write the proposal and it
passes, we won't know for sure, but I'm confident that's not the case
here.

2.                          If the implementation is too difficult
without them. I am told by implementers at least two companies that this
is not the case here either.

3.                          When it's difficult for the user to
determine where or what they've done that makes no sense. That's why we
DO have an extra rule requiring parenthesis around an assignment inside
of an expression to prevent "if(A=B)" when they really meant "if(A==B)".
On the contrary, "always B=1;" is still a legal statement, but that's
easy to catch. It's not always possible to make sense out of rules that
are designed to keep you from writing code that makes no sense.
Out-of-bounds array indexing and null class handle de-references are
easy for tools to catch, and they have to do that anyways.

 

I would only go through the trouble of removing an existing restriction
if the above can be satisfied AND I see a benefit to the user. I'll get
to that when I submit the proposal.

 

Dave

 

 

> -----Original Message-----

> From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com]

> Sent: Friday, November 03, 2006 12:12 AM

> To: Rich, Dave; sv-bc@eda-stds.org

> Subject: RE: [sv-bc] Is dynamic variable written in continuous
assignment

> 

> Dave,

> 

> > Those cases are both legal. The array as an aggregate is a static

> > variable. The LRM is currently restricting references to members of

> the

> > array in non-procedural contexts.

> 

> [SB] That should be clarified if the restriction remains. I was also

> fooled.

> 

> > By the way, I have on my to-do list writing a proposal to remove
that

> > restriction on dynamic variable members (just leaving the
restriction

> on

> > automatics in place). It really should be up to the user to avoid

> > out-of-bounds array indexing or null class handle de-references.

> 

> [SB] Could you explain your philosophy as to when to leave the

> responsibility to the user to get things right and when to protect him

> from himself?

> 

> Thanks,

> Shalom