10.2.3 Amplification

[hahn]

Hi,

I find the amplification of rule 10.2.3 confusing.

In general I wonder what the difference to a simple "no implicit conversion from unscoped enumeration type without underlying type to numeric type" (plus the exception for static_cast in bullet point 3) is?

In particular, as example, for the following code

Code:

enum E {E1, E2};
int f(int);
E operator+(E, E);
int main() {
  E e = E1;
  f(e); // Compliant? (1)
  e = e + e; // Non-compliant (2)
}

I wonder whether (1) should be compliant or not. At least it is not listed in the amplification, but seems like a problematic case anyway.
In turn, should (2) be non-compliant as operands to "arithmetic operator" are explicitly listed in the amplification, while I think this case is absolutely fine.

It would be great to get a clarification on what the rule intends.

[misra cpp]

Taking point (2) first,  you're right - as the rule is written this is non-compliant but doesn't violate the intent of the rule. We should possibly have made an exception for use in overloaded operators. However, we currently have no plans to change this, as it seems like a rather edge case and the user always has the options of deviating the rule for this usage. If we get more queries that suggest that this is a common use case, we'll reconsider.

For point (1), No this is non-compliant. Bullet 3 of the Amplification says such values 'shall not be used ... as the source of an assignment...'. Note that 'assignment' is in quotes, meaning it is being used as defined elsewhere in the document. The C++ standard defines contexts for the use of values: assignment, returning, passing as a parameter and initialisation.  MISRA rules usually apply to all four context, so rather than keep listing all four, somewhere we say 'for this document 'assignment' is taken to mean assignment, returning, passing as a parameter and initialisation'. Hence passing the enumeration value as a function parameter is 'assignment' as far as the rule is concerned.

We admit this could be clearer, so we intend to define a term 'general-assignment' in the glossary and modify all the rules that use 'assignment' to mean these four cases to use 'general-assignment'. 

The problem with  "no implicit conversion from unscoped enumeration type without underlying type to numeric type" is that we want to allow the use of enumeration types as an array index.