[sv-ec] Mantis 1356 Champion Feedback regarding 11.4.11

From: Tipp, Brandon P <brandon.p.tipp@intel.com>
Date: Wed Oct 26 2011 - 14:57:55 PDT

I received the following feedback from Shalom offline regarding updating 11.4.11 for 1356:

>I am ok with requiring interface class references to be equivalent for the ternary operator.

>

>But:

>

>1. What about where one expression is an interface class reference and the other is 'null'?

>2. What is the behavior if the condition has an ambiguous value?

>

>I think those cases should be clarified.

For his first point, if 11.4.11 is left alone, then it would be illegal for one expression to be an interface class while the other is null, (unless the null was typecast to be equivalent). I can change just the major bullet, to state that the cases a)-e) apply for interface classes as well as classes (which covers a few mixed cases with interface classes) but still not attempting to cover cases where two different classes implement one or more common interface classes. I wanted to send this out to the reflector to see if that is acceptable.

For his second point, if 11.4.11 is left alone, then this would apply:

For nonintegral and aggregate expressions, if cond_predicate evaluates to an ambiguous value, then:
- If the first expression and the second expression are of a class data type and if the conditional operation
is legal, then the resulting type is determined as defined above and the result is null.
- Otherwise, both the first expression and second expression shall be evaluated, and their results shall
be combined element by element. If the elements match, the element is returned. If they do not
match, then the default-uninitialized value for that element's type shall be returned.

I believe that the way that we defined it, an interface class is not a class data type, so you'd be forced into the second clause here which would require creating some sort of combined object. Instead, I believe that the first clause should be modified to cover interface classes as well, so that null is the result.

I've attached a working version of rev13 (doc) with both changes added to the proposal, so that it would be easier to talk about it and just remove it if that isn't what's desired.

Thanks,
-Brandon

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

Received on Wed Oct 26 14:58:45 2011

This archive was generated by hypermail 2.1.8 : Wed Oct 26 2011 - 14:58:53 PDT