My votes below. Thanks, -Tom ________________________________ From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org] On Behalf Of Mehdi Mohtashemi Sent: Tuesday, April 28, 2009 4:36 AM To: sv-ec@eda.org Subject: [sv-ec] email ballot: response due by 11:00am PDT Friday May 1 2009 We are conducting an email vote on the following issues related to the p1800-2009 draft 8 LRM Ballot comments. - Deadline is 11:00am PDT Friday May 1 2009. This is a shortened time voted on sv-ec meeting of April 27 2009, 4 days. - An issue will pass if there are zero NO votes and half of the eligible voters respond with a YES vote. - A NO vote must be accompanied with a reason. The issue will be reviewed at next meeting of sv-ec. - Note that we are referencing both ballot id and mantis id if both exist. Please read the description of each carefully. - Mark your vote with an x. - Note: There are many items in this email ballot, please review carefully. - Please note if a mantis item is specified and listed below along with the ballot comment id it must have a proposal attached for vote. Eligible voters as of April 27 2009 sv-ec meeting are as follows: 17 members. NOTE: sv-ec voted to include Shalom in the eligible voter list. Arturo Salz Cliff Cummings Dave Rich Francoise Martinolle Neil Korpusik Ray Ryan Gordon Vreugdenhil Steven Sharp Stu Sutherland Heath Chambers Don Mills Jonathan Bromley Mark Hartoog Tom Alsop Mike Mintz David Scott Shalom Bresticker id 48 allow for future enhancement _____ YES _____ No [Alsop, Thomas R] Abstain, I wasn't involved in the discussions and I don't see enough information in the spreadsheet to understand what future enhancement is currently being tabled. id 54 allow for future enhancement ___X__ YES _____ No id 16, 17 sv-ec agrees with sv-cc resolution to keep these regions for future use. Reject svdb 2632 statement. ___ X __ YES _____ No id 19 No action required ___ X __ YES _____ No [Alsop, Thomas R] Assuming that we are keeping the Preponed PLI region in the LRM. That is my vote, that it doesn't change. id 20 svdb 2634 (svbc issue) sv-ec votes as well to accept the proposal as well. ___ X __ YES _____ No http://www.eda.org/svdb/view.php?id=2634 id 105 (id 110 is duplicate of 105) No action required ___ X __ YES _____ No id 115 No action required _____ YES __X__ No [Alsop, Thomas R] This is a small change and makes sense. I would personally suggest just striking out the '(up to N-1) completely as it's just confusing, however the proposed change is more accurate, although again it does not make sense WRT to the 'M is 3 and N is 3' example that is provided. id 35, svdb 2705 __X__ YES _____ No http://www.eda.org/svdb/view.php?id=2705 ids 36,37,38,39,40 svdb 2700 __X__ YES _____ No http://www.eda.org/svdb/view.php?id=2700 id 41, svdb 2681 __X__ YES _____ No [both svbc and svec will vote on this] http://www.eda.org/svdb/view.php?id=2681 id 42, svdb 2682 __X__ YES _____ No http://www.eda.org/svdb/view.php?id=2682 id 43 and id 45, svdb 2430 __X__ YES _____ No http://www.eda.org/svdb/view.php?id=2430 id 44, svdb 2701 _____ YES __X__ No [both svbc and svec will vote on this] http://www.eda.org/svdb/view.php?id=2701 [Alsop, Thomas R] I have a lot of issues with the wording and understanding on this proposal for the new sub-clause 7.11.5. 1. 'Tools' should be 'Implementation'. 2. The third sentence states that "For any such violating operation, a warning shall be issued", but then the next sentence it states "Tools should issue exactly one warning". In clause 1.5 the conventions for 'shall', 'should', 'may', and 'can' are clear. I just want to make sure we are being clear in this new sub-clause WRT to these conventions. Seems like the 4th sentence should read that "Implementations shall issue exactly one warning..." 3. This sentence really confused me "If a violating operation attempts to write more than one element of a bounded queue, any element with index less than or equal to the bound shall be written exactly as it would be if the queue were unbounded." Perhaps an example would help. id 46, svdb 2706 __X__ YES _____ No http://www.eda.org/svdb/view.php?id=2706 id 47, svdb 2713 _____ YES __X__ No http://www.eda.org/svdb/view.php?id=2713 [Alsop, Thomas R] Just want to understand why the proposal is using "Error, see text"? What text? Is this something the implementations are expected to print out? Can we just put "Error"? id 57, svdb 2698 _____ YES __X__ No http://www.eda.org/svdb/view.php?id=2698 [Alsop, Thomas R] I am not convinced that 'pure' is required in order to create what is coined a "pure virtual method'. It's really ambiguous and seems like you can create a prototype virtual method and any level of abstract class hierarchy and only be forced to override it when you extend it to a non-abstract class and hence create the object out of it. I guess I am asking what the intent behind the 'pure' keyword is? If an abstract class at any level only prototypes a method, does that mean we have to label it 'pure'. id 65, svdb 2723 __X__ YES _____ No http://www.eda.org/svdb/view.php?id=2723 id 67, svdb 2358 __X__ YES _____ No http://www.eda.org/svdb/view.php?id=2358 id 80, svdb 2596 __X__ YES _____ No http://www.eda.org/svdb/view.php?id=2596 id 102, svdb 2718 __X__ YES _____ No http://www.eda.org/svdb/view.php?id=2718 id 106, svdb 2710 __X__ YES _____ No http://www.eda.org/svdb/view.php?id=2710 id 107, svdb 2711 __X__ YES _____ No http://www.eda.org/svdb/view.php?id=2711 id 181, svdb 2514 __X__ YES _____ No http://www.eda.org/svdb/view.php?id=2035 [Alsop, Thomas R] This should be svdb 2035 id 182, svdb 2514 _____ YES __X__ No http://www.eda.org/svdb/view.php?id=2514 [Alsop, Thomas R] I agree with the premise of the proposal, just not with some of the wording as it's not consistent with the draft8 wording. Specifically the references to 'concrete type' (Clause 8.24, third paragraph on page 142). --> "A generic class is not a type; only a concrete specialization represents a type. In the example above, the class vector becomes a concrete type only when it has had parameters applied to it, for example" But this proposal states "A pure constraint represents an obligation on any concrete (non-virtual) derived class", defining a concrete class to a non-virtual class. I'm just unclear about using the wording of 'concrete'. id 183, svdb 2510 __X__ YES _____ No http://www.eda.org/svdb/view.php?id=2510 id 184, svdb 2473 CLOSE 2473, id 184 requires no further action: [ Draft8 says An associative array type or class shall be illegal as a destination type. So this has already been made illegal.] __X__ YES _____ No http://www.eda.org/svdb/view.php?id=2473 id 185, svdb 2342 __X__ YES _____ No http://www.eda.org/svdb/view.php?id=2342 id 186, svdb 2288 __X__ YES _____ No http://www.eda.org/svdb/view.php?id=2288 id 192, svdb 1256 __X__ YES _____ No http://www.eda.org/svdb/view.php?id=1256 svdb 2719 for the following ids id 58 __X__ YES _____ No id 60 _____ YES __X__ No [Alsop, Thomas R] Is it just me or did we forget the second 'typedef' change to 'type' in the previous sentence? id 61 __x__ YES _____ No id 104 __x__ YES _____ No id 108 __x__ YES _____ No id 112 __x__ YES _____ No id 117 __x__ YES _____ No id 118 __x__ YES _____ No id 119 __x__ YES _____ No id 122 __x__ YES _____ No id 137 __x__ YES _____ No http://www.eda.org/svdb/view.php?id=2719 -- This message has been scanned for viruses and dangerous content by MailScanner<http://www.mailscanner.info/>, 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 Tue Apr 28 18:11:57 2009
This archive was generated by hypermail 2.1.8 : Tue Apr 28 2009 - 18:12:40 PDT