Here is the result of the email vote that closed on October 10th 2007. Eight mantis passed, 5 did not pass. Voted: 10 Dave Rich, Gord, Don, Geoffrey, cliff, Heath, David Scott, Mike Burns, Neil, Ray, Did not vote: 5 Arturo, Francoise, Steven, Stu, Mark PASS: 339, 1384, 1615, 1679, 1871, 1897, 1928, 2007. DID NOT PASS: 1336, 1560, 1594, 1608, 1715. [The full details on the vote are appended at the bottom of this email] 339 YES 10, NO 0 1336 YES 8, NO 2 1338 YES 10, NO 0 1560 YES 9, NO 1 1594 YES 9, NO 1 1608 YES 9, NO 1 1615 YES 10, NO 0 1679 YES 9, NO 0 [Abstain 1] 1715 YES 9, NO 1 1871 YES 10, NO 0 1897 YES 8, NO 0 [Abstain 2] 1928 YES 10, NO 0 2007 YES 10, NO 0 We will review the failed proposals during our next meeting on Monday October 15, 2007. - Mehdi ================================================================= 339 Yes 1111111111 No 1336 Yes 1111n111n1 MichaelBurns: Friendly amendment: this sentence needs wordsmithing: 13.4.5, 2nd sentence: "Thus, a process calling a function shall return immediately." I think I know what it's trying to say, but the wording seems wrong - processes don't return. How about this: "Thus, a process calling a function shall not block, and shall continue execution immediately when the function returns." I vote yes even if people argue with my amendment. No 11 Cliff: I think there are problems with the example (no constructor). The final block claims that any statement that is legal in a function is legal in an always block. This now permits nonblocking assignments to be used in a final block, which I am not sure is a good idea in a final block. I will change my vote to yes if the following changes are made. 1. There appears to be something wrong with the sentence added to 9.3.2 From: Use restricted inside function calls (See 13.4) Functions To: Has restricted usage inside function calls (See 13.4). 2. Section 13.4.4 Brad offered the following suggestion. This would make this change consistent with the line immediately above it. From: A constant function shall not have any fork constructs. To: A constant function shall not contain any fork constructs. 3. Section 13.4.5 From: From within a function, a fork-join_none construct may contain any statements that are legal from within a task. To: Within a function, a fork-join_none construct may contain any statements that are legal within a task. propoasl updated by Dave. 1384 Yes 1111111111 No 1560 Yes 11111111n1 No 1 Neil: I will change my vote to yes if this one change is removed from the proposal. Why change the word prototype to syntax? All of the Queue methods described in 7.11.2 mention the word prototype. Why is it being changed to syntax for just the delete method? 1594 Yes 1n11111111 Geoffrey:Friendly amendment in 1594, "one of the operand is" -> "one of the operands is" [DR] Although the proposal seems to address 1608 Neil: with the following friendly ammendments Two minor word-smithing problems: 1) operand --> operands 2) wild card --> wildcard From: The logical equality (or case equality) operator is a legal operation if either operand is a class object or the literal null and one of the operand is... To: The logical equality (or case equality) operator is a legal operation if either operand is a class object or the literal null and one of the operands is... From: wild card To: wildcard No 1 Gord: I don't have any objection to what is intended, but the wording says: ...the operator compares the values of the class objects... I think we should say "class object handles" here so that there is no confusion about interpreting this as a member-wise comparison. With the word "handles" added, I would vote "yes". 1608 Yes 11111111n1 [DR] Although the proposal seems to address 1594 Geoffrey Friendly amendment in 1608, "as if the expression was the literal null" -> "as if the expression were the literal null" No 1 Neil: section 8.4 There is something wrong with this sentence "Assignment of a class object which class datatype is assignment compatible with the target class object" Something like the following seems more correct: Assignment of a class object which is datatype assignment compatible with the target class object 1615 CLOSE 1615, covered by 1336 Yes 1111111111 No 1679 Yes a111111111 No ABSTAIN 1 [DR] Abstain - original wording was clear 1715 Yes n111111111 Neil: Minor correction: I think that the reference to clause 15 should actually be to 15.5. No 1 [DR] An informative note this lengthy implies that the normative text is not clear enough, or this enhancement it not really justified. 1871 Yes 1111111111 No 1897 Yes 1111a11a11 No ABSTAIN 11 Cliff: (This is a rather complex enhancement to be passed by an email vote) MichaelBurns: I haven't been following this and there's a lot here. 1928 Re-approve. If needed open other mantis Yes 1111111111 Neil: If none of John's comments are incorporated into 1928 we should open a new mantis item to address John's feedback. No 2007 Yes 1111111111 No 339 typos in queue methods 1336 Rules for allowed statements in a function 1384 bit stream cast and pack/unpack for protected./local members 1560 Queue delete() method for entire array 1594 conditional operator for class handles incorrect 1608 equality, inequality and conditional operator rules for class handles 1615 can processes spawned by functions execute blocking statements? 1679 string casting statement unclear 1715 Triggered property of a clocking block 1871 clarification needed for illegal/ignore transition bins 1897 clarify "union of all significant bins" and "overlapping bins" in coverage computation 1928 clarification of coverpoint value resolution (18.5.6) 2007 7.9.4: rules about int type index for associative arrays -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Fri Oct 12 15:24:31 2007
This archive was generated by hypermail 2.1.8 : Fri Oct 12 2007 - 15:24:41 PDT