[sv-ec] comments on 1356

Here some comments on the latest proposal

COMMENT #1
===========
Section 8.25
page 1:

I would recommend to reword the 1st paragraph to be more precise and more LRM language like.

I propose to change:

"SystemVerilog introduces a type of class called an interface class.

This is not to be confused with the

interface construct (see section 3.5 Interfaces). An interface class is a requirement to provide

implementations for a set of methods. The provided implementations shall satisfy the requirements of a

virtual method override (see 8.19). An interface class makes it unnecessary for related classes to share a

common abstract superclass or for that superclass to contain all method definitions needed by all subclasses.

This interface implementation allows classes to support common behaviors without sharing any

implementation."

TO:

"SystemVerilog defines a new type of class called an interface class. A regular (non interface) class can be declared as implementing an interface class. This creates a requirement for the non interface class to provide implementations for a set
of methods of the interface class as if the methods were virtual (see 8.19). An interface class makes it unnecessary for related classes to share a commont abstract superclass or for that superclass to contain all method declarations needed by all subclasses. An interface class allows classes to support common behaviours without sharing any implementation."

COMMENT #2
===========
Page 2:
typo:

cover groups should be covergroups

COMMENT #3
===========

Change:

Constraint blocks, cover groups and nested classes (see 8.22) shall not be allowed in an interface class.

to:

Constraint blocks, cover groups and nested classes (see 8.22) are illegal in an interface class.

COMMENT #4
===========

Page 2 question about this sentence:

"An interface class can inherit from one or more interface classes through the extends keyword, meaning that it inherits all the

member types, pure virtual methods and parameters of the interface classes it extends, except for any member

types and parameters that it may hide."

 I would add a reference to the section that talks about name conflict resolution.

COMMENT #5

===========

Page 2

"All pure virtual methods from an interface class shall have overridden implementations in order to be implemented by a non-abstract class."

 The sentence above suggests that one can have an abstract class implementing an interface class but the abstract class is NOT

required to provide implementations of the virtual methods of the interface class. Is that right? Is the scenario of an abstract class implementing an interface class legal?

COMMENT #6
===========

Page 2

"A subclass implicitly implements all of the interface classes implemented by its superclass. An implementation may be

provided by an inherited virtual method implementation in a superclass of the implementing class."

 Why saying "implicitly"? I think it would be better to say " shall implement" and drop implicitly. The sentences after

define that the subclass may inherit or define the implemention from its superclass.

COMMENT # 7
===========

Page 2

Missing "the"

 An implementation may be

provided by an inherited virtual method implementation in a superclass of the implementing class. A

virtual class shall define or inherit a pure virtual method prototype or virtual method

implementation for each pure virtual method prototype in each implemented interface class. The

keyword virtual shall be used unless the virtual method is inherited.

COMMENT # 8
===========

Page 3

You probably should add the superscript 7 and add the footnote to the syntax (no need to have it in green)

COMMENT # 9
===========

Page 4

An interface class may extend, but not implement, one or more interface classes; meaning that the sub

interface class aggregates interface class members and can add additional member types, pure virtual method

prototypes and parameters.

The term "aggregates" is awkward here. I suggests to say "includes all". I think "can" needs to be changed to "may" I would suggest the following wording:

meaning that the sub interface class includes all interface class members and may add additional member types, pure virtual method prototypes and parameters.

COMMENT # 10
===========

Page 5

I suggest to change "the definition" to "the implementation" in the sentence below:

 Ex tClass fulfills its requirement to implement IntfClass by providing an implementation of funcExt

and by inheriting the definition of funcBase from BaseClass.

COMMENT # 11
===========

Page 5

I think that "cannot provide" is not right. It should have been "does not provide". Since this is legal to have a non-virtual method in a

class which does not implements an interface class.

 " An inherited non-virtual method cannot provide an implementation for a method of an implemented interface class. "

COMMENT # 12
===========

Page 5

The following sentence is awkward.

 " Parameters and typedefs within an interface class are inherited into the scope of extending interface classes,

but are not inherited into the scope of implementing classes. "

I suggest to reword as:

Parameters and typedefs within an interface class are inherited by the derived interface classes,

but are not inherited by the implementing classes.

COMMENT # 13
===========

Page 5

I would replace this

Example 1: type definitions and parameters are inherited by extends

with:

Example 1: type and parameter declarations are inherited by extends

COMMENT # 14
===========

Page 5

SImilarly:

 Change:

 Example 2: type definition and parameters are not inherited by implements and must be specified with scope

to:

 Example 2: type and parameter declarations are not inherited by implements and must be specified with scope operator

COMMENT # 15
===========

Page 6

The usage of "parameter" means both value and type parameters, in the sentence below, the intent of using parameter

should be limited to "type parameter".

Change parameter to type parameter in the sentence below.

Also change" demonstrate" to "illustrate"

8.25.4 Type Usage Restrictions

A class shall not implement a type parameter, nor shall an interface class extend a type parameter; even if the type parameter

or defined type resolves to an interface class.The following examples illustrate this restriction and are

illegal:

COMMENT # 16
===========

Page 6

 This is probably beyond the scope of this mantis item, but I would like to see the restriction for fwd typedef

to also apply to non interface classes.

Are we allowing forward typedefs of interface classes? If we are not, they it would be better to state that forward typedefs of interface classes are illegal. It seems that it is the net effect of the restrictions described below.

typedef class INTF;

interface class INTF;

endclass

I would also rephrase the paragraph:

A forward typedef shall not be used as an implemented or extended interface class. All interface class

definitions shall be declared before the implementation or extension of the interface class is reached.

TO:

 A class cannot implement a forward typedef for an interface class. An interface class cannot extend from a forward typedef of an interface class.

 I would also change:

" All interface class definitions shall be declared before the implementation or extension of the interface class is reached. "

TO:

" All interface class declarations shall appear before the ir use as implementation or extensio n . "

COMMENT # 17
===========

Page 6

It would be nice if the partial example would refer to the section containing the complete example for the class

declarations.

COMMENT # 18
===========

Page 7, section 8.25.6

 The keywords interface class should be bold and in courier font:

 interface class extends

COMMENT # 19
===========

Page 7, section 8.25.6.1

 typo:

implemenationof

COMMENT # 20
===========

Page 7, section 8.25.6.1

 I would change parameter to "arguments" and "will" to "shall"

If the argument and/or return types of the methods involved in a method name collision are of incompatible

types, an error shall occur. Example:

What is an incompatible type? Should we refer to virtual method prototype matching instead (manits item 2950)

COMMENT # 21
===========

Page 8, section 8.25.6.2

Change definition to declaration

8.25.6.2 Parameter and type declaration Inheritance Conflicts and Resolution

Interface classes may inherit parameters and type declarations from multiple interface classes. A name

collision will occur if the same name is inherited from different interface classes. The subclass shall provide

parameter and/or type declarations which override all such name collisions.

...

PutGetIntf overrides T with a type declaration to resolve the conflict.

COMMENT # 22
===========

Page 8, section 8.25.6.3

 I think that the sentence below should not use "shall". I think it meant to say that diamond inheritance never causes a name

conflict.

 I would rewrite:

 In no case shall diamond inheritance cause a conflict requiring resolution.

as:

Diamond inheritance never causes a name conflict.

COMMENT # 22
===========

Page 8, section 8.25.6.3

Please remove the extra semi colon in the class declaration

interface class IntfExt3 extends IntfExt1, IntfExt2;

;

endclass

COMMENT # 23
===========

Page 9

A given parameterization of a class is called a specialization. We should use the proper terms in the paragraphs below:

Change

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 inherited from different paths using any different parameter

values. For example:

to:

Each parameterization of a parameterized interface class is a interface class specialization . Therefore, it shall

be a conflict if a parameterized interface class is inherited from different paths using different parameter izations . For example

And change:

In the above example, there are two different parameterizations of the interface class IntfBase. Each of

these parameterized versions of IntfBase is a unique class, therefore there is no diamond inheritance and

there is a conflict of the parameter T which must be resolved.

to:

 In the above example, there are two different parameterizations of the interface class IntfBase. Each of

these parameteriz ations of IntfBase is a unique class specialization , therefore there is no diamond inheritance and

there is a conflict of the type parameter T which must be resolved.

COMMENT # 24
===========

Page 9

 I would reword this:

 It shall be illegal to use an interface class to partially define a virtual class without fulfilling the interface

class prototype requirements. In other words, when an interface class is implemented, the virtual class must

do one of the following:

* Fully define the method as per the prototype requirement

* Declare the method as pure and re-declare the method prototype.

As:

 It shall be illegal to use an interface class to partially define a virtual class without fulfilling the interface

class prototype requirements. In other words, when an interface class is implemented by a virtual class , the virtual class must

do one of the following:

* Provide the method implementation for the declared method prototype

 * Re-declare the method prototype with the pure qualifier.

COMMENT # 25
===========

Page 10

I would change subroutine to method in the following sentence.

Method declarations within Interface Classes may have default argument values. The default expression shall

be constant and is evaluated in the scope containing the subroutine declaration.

Do we mean "shall be a constant expression" instead of "shall be constant"

COMMENT # 26
===========

Page 10 section 8.25.9

 change cover group to covergroup, instead of "shall not be allowed" use " shall be illegal"

or say: Constraint blocks and coverroups shall not be declared in interface classes.

8.25.9 Constraint Blocks, Cover Groups, and Randomization

Constraint blocks and cover groups shall not be allowed in interface classes.

COMMENT # 27
===========

Page 10 section 8.25.9 The whole paragraph needs rewording,

While inline constraints shall also be

legal, interface classes cannot contain any data meaning that inline constraints will only be able to express

conditions related to state variables and are therefore of very limited utility. Use of rand_mode and

constraint_mode shall not be legal as a consequence of the name resolution rules and the fact that interface

classes are not permitted to contain data members.

Proposed change:

 Inlined constraints for a randomize call of a interface class handle are of limited use since interface classes cannot contain any data member. rand_mode and constraint_mode calls are illegal for an interface class object.

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