SV-EC Ballot resolution committee meeting. Monday June 15 2009 11:00am - 1:00pm PDT [ http://www.eda.org/sv-ec/Minutes/SV-EC_Meeting_June_15_2009_Minutes.txt ] With the new calculations for voting rights below (rounded)... 3/4 rule = 0.75 * 7 = 5.25 Meeting number: ------------------------------------------------------------------------- 00000000 00000000 11234567 Meeting Days: ------------------------------------------------------------------------ (12201001 ) Day (30741185 ) (00000000 ) Month (44455666 ) (00000000 ) Year (99999999 ) ------ Attendees -------------------------------------------------------- (A-AAAAAA ) Arturo Salz 7 (A-AAAAA- ) Cliff Cummings 6 (AAAAAAAA ) Dave Rich 8 (AAAAAAAA ) Francoise Martinolle 8 (AAAAAAAA ) Mehdi Mohtashemi 8 (AAAAAA-- ) Neil Korpusik 6 (AAAAA--A ) Ray Ryan 6 (-AAAA-Aa ) Gordon Vreugdenhil 6 (AAAAAAAA ) Steven Sharp 8 (A-AAAA-- ) Stu Sutherland 5 (AAAAA-A- ) Heath Chambers 6 (AAAAAA-A ) Don Mills 7 (AAAAAAAA ) Jonathan Bromley 8 (AAAAAAAA ) Mark Hartoog 8 (AAAAA--- ) Tom Alsop 5 (A-A-A--- ) Mike Mintz 3 (AAAAAAA- ) David Scott 6 (-------a ) Jamie LaFlamme (1) proxy for Gord, June.15.2009 =================================================== v0vvv-v v => voting; - => non voting meetings 10 People have joined the meeting.[Jamie LaFlamme as proxy for Gord. Quorum acheived. ** Minutes taken by Jonathan Bromley and Mehdi Mohtashemi ////////////////// June 15, 2009 ///////////////////////// Agenda: 1. Review IEEE patent policy ----------------------------- http://standards.ieee.org/board/pat/pat-slideset.ppt The chair directed everyone's attention to the patent policy. 2. Review meeting minutes/Notes: ------------------------------------------------- Minutes of June 8 2009 meeting http://www.eda.org/sv-ec/Minutes/SV-EC_Meeting_June_8_2009_Minutes.txt Move: Jonathan Second: Francoise Abstain: Oppposed: meeting minutes approved 3. Updates from p1800WG / ------------------------------------------------------ Next p1800WG meeting will be held on June 17 2009. 4. Review email vote (due June 11 2009) issues ------------------------------------------------------ NOTE: Mantis 2736 is the master list for sv-ec ballot feedback. Use it to reference all sv-ec mantis items addressing ballot comments. Mehdi: reporting that the recent email vote (due June 11 2009) had not achieved quorum so we must review all items. Mantis 2380 ids 33, 34, 56 (array assignment compatibility): Jonathan: clears major contradiction. Move: Jonathan, approve 2380, propoasl: 2380-proposal-v2A.pdf Second: Steven Abstain: Oppposed: approved unanimously Mantis 1517 id 189 (array reduction methods act as operators, not functions, in constraints): 1517_reduction.pdf Jonathan: Some minor fixes to the proposal, 1517_reduction.pdf added as bugnote 8539. Arturo: type of with-expression must be self-determined, even when rewritten (unrolled) as an inline expression. Ray: It needs a cast, as in Dave Rich's example. If with clause is not there, sum is with of A, 1000 does not affect it. Steven: Can we isolate the rewriting rule so it applies only for constraints? Would reduce risk of misinterpretation. Arturo: offerring additional text to avoid the problem - implicit cast to type(A[i]) Dave: example shows that the result is cast to an int. Can we use the same definition wording as for "inside" operator? NOTE: Dave Rich will update the proposal for vote later in the meeting. Mantis 2715 id 21 (is string singular?): Jonathan: the latest proposal is 2715-2.pdf Arturo: my preference would be to keep it as aggregate, Steven: it's counterintuitive for string to be singular, Arturo: exact same feeling. Move: Jonathan to accept proposal 2715-2.pdf Second: Francoise Abstain: Opposed: approved unanimously 5. Other ballot issues ------------------------------------------------------ Mantis 2606 id #62 (visibility of types in extern method body): Francoise: a couple of weeks ago, Gord wanted some clarificaitons. It is not completely clear. It doesn't describe resolution of names referenced in the body but not in the prototype. Mark: what is not clear? Francoise: it resolves the ballot comment partially Mark: there's a typo in the proposal: extern body needs C:: prefix to function name. Steven: it does not resolve every situation, but proposal is an improvement. Arturo: you're touching upon the same issue. Steven: out of body implementation, you resolve to class first. Jamie: Gord seemed to agree with that approach even though it's not explicit in the proposal. Steven: uncertainty about items outside the class scope. Can extern body see everything that's declared in the lexical scope between the class and the extern body? Francoise: yes. What if C is a derived class? Steven: extern body looks at the whole class scope of C, including base class properties etc. Arturo: as long as you do not talk about the ordering inside the class, Steven: does not absolutely specify the ordering. Francoise: implemntors are agreeing on the algorithm. Steven: reitrating ballot comment questions, how do the name gets resolved. there are disagreements on those details. NOTE: more discussion pursued on the typedefs, properties, forward typedefs, etc. Francoise: It's probably the best we can do. Steven: Better to approve it than not. Arturo: disagrees; you can leave the example, perhaps drop the 2nd sentence in proposal, forward reference within the class. Steven: LRM does not say that rule is there, must not allow forward references to types. Arturo: disagreement on this. This is still complicated if class scope resolution operator :: is used. Jonathan: can we decouple the issues. Arturo: forward type defs and classes are problematic, Steven: 2nd sentence: prototypes access types Mark: reiterates that you must know if an identifier denotes a type. Steven: A compromise; could change "properties and types" to "types"? Francoise: that would allow for forward reference to properties within a class, just changes name resolution inside classes, Steven: we can approve it and see what happens in champions Arturo: we decided to leave this as is, leave it unresolved. Steven: No, it's a big problem, LRM needs to be explicit, there's no consensus, let's vote on it. NOTE: Jonatahn pointed out minor errata as well, two keywords type should be typedef, Francoise will fix them during the discussion. Francoise: downloading new version with the typos fixed: 2606_proto_refs[2].pdf Arturo: If this is accepted it would surely trigger a negative ballot response Move: Francoise to approve mantis 2606 proposal 2606_proto_refs[2].pdf Second: Steven Abstain: Jonathan [outside of core competency] Opposed: Mark, Arturo, [outside of scope this ballot raised, we would vote yes if the second sentence was re-phrased to type declaration] Steven: It reduces consensus, even though it is a better way to go. I am in favor of proposal but concerned it would trigger negative ballot. Total: YES: Dave, Ray, Jamie, Don, Francoise NO: Mark, Arturo, Steven, ABSTAIN: Jonathan Mehdi: I will have to check the bylaws and procedures with respect to the voting rules. AI: Mehdi - check procedures to finalize the vote count for mantis 2606. Mantis 1517 id 189 1517_reduction.pdf Dave: have uploaded a new proposal, fixing the typos, Move: Dave - move to approve 1517, proposal 1517_reduction.pdf Second: Arturo Abstain: Opposed: unanimously approved. Mantis 1721 id #188 (first/last ordering for array locator methods): the proposal is: 1721_find.pdf Dave: issue about ordering vs. traversal, left alone, find first and last, closest to the left and right first and last, associateive array, ordering closest to the first and last of method. Arutro: maybe to reword: associative array, element index is smallest. relational operative are defined, Steven: defined by first and next operators. Dave: element returned by the first or last associative array, closest to index returned by the first or last Move: Dave - to accept 1721, proposal: 1721_find.pdf Second: Jonathan Abstain: Opposed: unanimously approved. Mantis 2607 id #63 (forward typedef to parameterized classes): Francoise: default class type, Gord wanted to have it so we know parametrized class, only required when we have forward class type. Mark: I do not see the need for this #() , what is the reason for the requirement? Franocise: if typedef in compilation unit, full declaration may be much later, implementation doesn't know whether the class is parameterized. Arturo: you can resolve to the design if you do not know what it is. Mark: Would it be an error to use #() on a non-parameterized class? If not, then you can infer #() on any such! Arturo: if you use this with :: operator, Mark: you know type or class Arturo: can you say c::foo, Steven: if you can use #() regardless, it tesll you this is class. Arturo: typedef class c; default class specialiasziton Steven: clarified that "typedef class C;" does not specialize C. Francoise: The proposal answers what I asked for in the ballot comment. #() makes implementation easier. Steven: Am not certain #() is needed.Is there a compatibility issue? Mark: this is a new requirement, bacward compatiblity issue, Francoise: #() has always been an error on unparamterizable class. Steven: paramterized class with zero parameters. Mark: What happens when the class is originally parameterless, but then it's changed to have a param with a default? Old code that didn't use #() would be invalidated. Arturo: does it add any value to users? Steven: it just gives parabemamterize class to use it Mark: almost certain to cause backward compabilitey, and divergence between implementation. Class scope references to static classes are not that common. Francoise: if I remove the requirement c#() would that resolve the issue? Jamie: Yes, Steven: Yes, but removeit from the example as well, will allow room for future change! - intentionally leave ambiguity in LRM. Francoise: I have uploaded a correspondingly modified proposal. Move: Francoise, to accept 2607, proposal 2607-rev2.pdf Second: Mark Abstain: Opposed: unanimously approved. 6. Next meetings in 2009 ----------------------------------------------------- Monday June 22 2009 11:00-1:00pm Keep next week's meeting, if not needed we will cancel. === action items list below is provided for members reference === not part of official meeting minutes ================= Action item list provided for sv-ec =================== ============ from June 15 2009 meeting =================== AI: Mehdi - check procedures to finalize the vote count for mantis 2606. ============ from June 8 2009 meeting =================== AI: Jonathan - 2575, 2698 put bugnotes on those Mantis items to record this resolution. AI: Jonathan - for 2744 add a bug note explaining this action. AI: Steven - for 2692: to copy-and-paste critical parts of that text to a new bugnote. AI: Francoise - proposals for 2606, 2607 AI: Mehdi - place 2380, 1517, 2715, for email vote, shortened, due June 11, ============ from June 1 2009 meeting =================== AI: Steven - 2575 resend his email vote response to Francoise on this point. AI: Francoise - update the proposal for 2575 with Steven Sharp's feedback. AI: Mehdi - mantis 1575 add to email vote. AI: Arturo - mantis 2738 create the pdf file. AI: David - mantis 2711 put together a proposal (do more word-smithing on the reflector) AI: Mehdi - mantis 2694 add to email vote. AI: Mehdi - mantis 2692 add to email vote. AI: Mehdi - mantis 1486 put up for email vote. AI: Dave; proposal for 1517 and 1721 AI: Jonathan - mantis 2715; prepared to write a proposal saying that strings are singular. ============ from May 11 2009 meeting =================== AI: Tom - mantis 2738 id 115 reload as a pdf (Neil can't see it). AI: All - last chance to point out anything that people want to work on. ============ from May 4 2009 meeting =================== AI: Francoise - put a proposal for id 19. AI: Mehdi - put mantis 2700 up for an email vote. AI: Steven - mantis 2713 update with a reference to "text above" AI: Mehdi - update 2719: friendly amendment for id 60 and remove id 122 AI: Mehdi - for 2711, check the rules for voting, yes/no/abstain items. AI: Tom - write a proposal for id 115 AI: Mehdi - for id 182 mantis 2514 put the proposal into an email vote AI: Dave - id 183 mantis 2510 will update the proposal to have a xref to 6.21. AI: Mehdi - id 183 mantis 2510 put up for an email vote AI: Arturo - send email on mantis 2597, id 49. AI: All - send email for any that remain open that should be done for this PAR. ============ from April 27 2009 meeting =================== AI: Stu - id 42; write a proposal (the third 'is'). Dave mentioned a second spot also. AI: Jonathan - id 138 put together a proposal (in the coverage section) AI: Mehdi - id 140 put into email vote - consider for next PAR. AI: Gord - id 52 and 64 create a proposal for an update to 8.22. Won't have time to review the whole LRM for other places to change. AI: Francoise - id 52 and 64 will make a more complete proposal. AI: Gord - id 51 will put together a proposal. AI: All - ids 67,53,55,109,111,49 send email on it. AI: Steven - id 21, will gather some input on this. mantis 2715 AI: Steven, Arturo, Gord - review the set of points in mantis 2715 (id 21) AI: Dave - send email to Mehdi on the mantis items that address his AI/s ============ from April 20 2009 continuation meeting =================== AI: Steven - row 146 id 47 create a proposal for updating the table. AI: Mehdi - row 148 id 48 add to an email vote, one of the canned responses should work. AI: Francoise - row 149 id 49 will add and email link to the mantis item. AI: Steven - row 150 id 50 will track down what text he thinks needs to be changed so that we can think of these as class members. AI: Francoise - will have a proposal by next meeting. AI: Arturo - row 151 id 51: take a look at this one (and line 152 id 52) AI: Francoise - add to mantis 2575 (line 150, id 50) AI: Mark - row 153 id 67write up a proposal AI: Francoise - row 154 id 53 write a proposal to move that one sentence earlier in this section. AI: Jonathan - row 158 id 182 will take a look at it. AI: Mehdi - row 167 id 183 add to the email vote.