[sv-ec] feedback on Mantis 1356

I am OK with the intent of the proposal, but the text needs more work. Here are some issues to start with.

1. In the syntax changes for 8.3, the semicolon is in the wrong place. It should be after the optional "implements" clause.

2. At the start of the text for 8.25, the use of the word "introduces" makes no sense for the standard. The proposal introduces interface classes to SV, but after the text is part of the standard, what is SV introducing them to? SV can't introduce them to SV, and it can't be introducing them to the domain of programming languages, since the concept already existed there.

3. In 8.25, saying that an interface class "is a requirement" is inaccurate. It is a type or perhaps a declaration. It creates those requirements, and they are its main purpose, but it isn't the requirement.

4. In 8.25, at the point where it says "The provided implementations shall", the reader has no idea what these provided implementations are. The text should first introduce the idea that there can be other class types that implement the interface class (though the exact way this is specified can wait). After the user knows that it is talking about some other class types, then they have a reference point to understand what those class types are required to do.

5. In 8.25, the third paragraph is disjointed. Adjacent sentences seem unrelated. It needs to be reorganized.

6. In 8.25.2, the sentence containing "aggregates" is difficult to parse. It takes rereading to figure out that "aggregates" is apparently being used as a verb here, since it is used as a noun everywhere else in the standard. Assuming that this is the intent, I would suggest another word that can't be read as a noun, such as "combines".

7. In 8.25.3, saying that parameters and types are "implicitly static" seems confusing. Yes, they are static and this is implicit, but why say this? Usually when the standard talks about something implicit, it is in contrast to another form that is explicit. So when somebody sees text saying that these are implicitly static, the next thought is "and how do I override that explicitly?" It could also be taken as specifying something special about interface classes. The intent is just to point out the fact that these things are static as in any class, and can be referenced with a class scope qualifier, as in any class. This is not helped by the use of the term "interface class select", which sounds like it is introducing a new concept. Presumably the intent is to talk about a class member select that uses an interface class handle. This text is presumably trying to specify that these static things can be accessed via a class scope, as with any class, but cannot be referenced from an instance name as they can be in other classes (though these aren't constant expressions there).

8. In 8.25.4, when talking about the restrictions on implementing or extending from parameters, it should specifically say "type parameters". Most readers probably think of value parameters first when they read the term parameter, which makes the sentence hard to understand until they reach something that makes it clear that it meant type parameters. Then they have to go back and reread it with that knowledge.

9. In 8.25.4, talking about the "implemented" or "extended" class seems potentially confusing. I understand the intent, but the terminology has not been used previously, so it may not be obvious.

10. In 8.25.6, I don't like the description of merging/inheriting symbols. I don't think it is an accurate description of the process of resolving the names.

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