1) 8.25.5.1 -- example has "function function". 2) 8.3 Grammar error. [implements interface_class_type [ ( list_of_arguments ) ] {, interface_class_type [ ( list_of_arguments ) ] } ] Should be: [implements interface_class_type {, interface_class_type } ] The list_of_arguments (in the extends part of the production) is related to the constructor call. Interface classes don't have constructors. 3) 8.25.1 Same grammar issue [ extends interface_class_type [ ( list_of_arguments ) ] {, interface_class_type [ ( list_of_arguments ) ] }] Should be: [ extends interface_class_type {, interface_class_type }] 4) 8.25.3.1 Should also restrict implements from interface based types. 5) The proposed re-wording for 8.15 ($cast) isn't quite right. It wouldn't allow a cast from an interface class type expression to a class type target (since the interface class could not possibly be a superclass of the class). I think that we could change the rewording of the second bullet to just: o the type of the source expression is an interface class 6) 8.25.4 Change the sentence: It shall be legal to assign an object handle to a variable of an interface class type that it implements. to: It shall be legal to assign an object handle to a variable of an interface class type that the object implements. 7) 8.25.4 "It shall also be legal to have multiple references of an interface class and use them to cast from one to another." This is potentially confusing -- you never have objects of an interface class type, only variables of those types. So how about: "It shall be legal to dynamically cast between interface class variables if the actual class handle is valid to assign to the destination." 8) 8.25.4 What is a "prototype interface class handles"? More generally, the entire sentence "It shall also be legal to cast implemented objects onto their prototype interface class handles" is not careful enough about object and type distinction. See comment 8. 9) It is legal to access parameters in an interface class as "IntfClass::param_name". Is it legal to have: IntfClass ic = some_object; int x = ic.param_name; In other words, are static data members (such as parameters) accessible as a select from a variable of an interface class type? 10) Syntax in 8.3: interface_class_type :: ps_class_identifier[parameter_value_assignment] should be: interface_class_type ::= ps_class_identifier[parameter_value_assignment] ^^^ 11) Syntax at the end of 8.25.1: interface_class_method ::= pure virtual method_prototype "pure" and "virtual" should be bold. 12) 8.25.2 The sentence: Conceptually an extends is considered a means to extend the content of the a superclass... is awkward. How about: Conceptually an extends clause is a mechanism to add to or modify the behavior to a superclass... 13) 8.25.2 Because virtual classes are abstract they may or may not fully define .. How about: Because virtual classes are abstract they are not required to fully define .. 14) 8.25.5.1 In the first example, I think I disagree with the requirement to have funcBase be defined in ClassExt. Doesn't that requirement conflict with the example in 8.25.2? I do agree with the second example and the examples in 8.25.5.2 and 8.25.5.3. 15) 8.25.5.3. The sentence: Each unique parameterization of a parameterized class is a unique class. Therefore, it shall be a conflict if a parameterized class is... should be: Each unique parameterization of a parameterized interface class is a unique interface class. Therefore, it shall be a conflict if a parameterized interface class is... 16) Can a handle to an abstract base class be used as a reference to an implemented method even if the method is not directly declared? So is the following legal: interface class intf; pure virtual function void f(); endclass virtual class base implements intf; endclass //... base b = some_valid_object_derived_from_base; b.f(); // <<<< is this legal? It is not clear from the proposal that this is legal although my expectation from committee discusion is that people would like it to be. We should carefully consider that choice. Allowing "base" to essentially inherit the pure function prototype weakens the distinction between "extends" and "implements" and also may pose later surprises if "base" doesn't implement everything. By requiring "base" to have all needed prototypes, one gets a clear picture at the point of the implements of what obligations may still be outstanding in the type hierarchy derived from base. So I'd prefer to require "base" to prototype all implemented methods or, at least, to disallow calls from "base" to an unprototyped implemented method. 17) Does the user need to explicitly indicate "virtual" on the first implementing definition or is that implied by the implements in the same way as it would be during inheritance? interface class intf; pure virtual function void f(); endclass class base implements intf; function void f(); endfunction endclass 18) The question of whether a pure virtual hides a non-virtual is still open. So is the following legal: class base; function void f(); endfunction endclass interface class intf; pure virtual function void f(); endclass virtual class der extends base implements intf; endclass class der2 extends der; function void f(); endfuntion endclass If you have: der d = some_legal_obj; d.f(); what is called? 19) Can one call randomize() via an interface class handle? Certainly on cannot use inline constraints, rand_mode or constraint_mode (which should be noted in the LRM). 20) What does $bits return for an interface class handle? How does this relate to streaming operators? Can one stream from/into an interface class handle? 11.4.14.1 needs to define streaming behavior for interface class handles. 21) 21.2.1.7 should permit interface class handles as well. 22) 6.22.5 should include interface class