RE: [sv-ec]Email Vote: Response requested by Friday July 1 2011 11:59pm

Mehdi,

My votes are below

Arturo

-----

1) Mantis 2794 _X_Yes ___No

[proposal: proposal-2794-3a.pdf]

(2) Mantis 2112 ___Yes _X_No

[proposal: 2112_NBA.pdf]

This proposal goes much further than just allowing non-blocking assignments to class members. It allows objects and class members in continuous assignments. I find this enhancement problematic - it seems to encourage a questionable methodology IMHO. There are also some other problems:

- Minor friendly editorial nitpick. Leave this sentence as it was: .. a null object handle is are illegal.

- What does this sentence mean, and why is it needed? An implementation shall not be required to reclaim an object at any time before the end of simulation.

(3) Mantis 2900 ___Yes _X_No

[proposal: 2900_assoc_lvalue2.pdf]

This proposal introduces an unnecessary inefficiency and ambiguity:

- The verbiage " ... the element appears in context of an assignment with a valid index." is unclear. What does that mean, precisely.

- The statement a[1]++; is equivalent to a[1] = a[1] + 1; However, the value of a[1] which is read first does not exist so presumably a[1] becomes 1 because the default value is 1. I don't believe this is clear and is full of pitfalls for users - for example if the array is integer a[1] would become X.

- In the statement b[2].x = 5; the L-value is b[2].x, not b[2]. I don't agree that this should create an array entry. It is not clear in which cases the compiler is required to check if the entry exists and create one. Furthermore, if the struct did not have default values, this would leave a[2].y uninitialized, which is probably undesirable.

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