Version 1.1 of acs/ac-00233.txt

Unformatted version of acs/ac-00233.txt version 1.1
Other versions for file acs/ac-00233.txt

!standard 4.5.7(18/3)          12-05-11 AC95-00233/00
!class confirmation 12-05-11
!status received no action 12-05-11
!status received 12-02-22
!subject Missinbg "else" in a conditional expression
!summary
!appendix

From: Adam Beneschan
Sent: Wednesday, February 22, 2012  5:20 PM

Just to clarify my analysis here:

The rule in 4.5.7(18) "If there is no ELSE dependent_expression, the
if_expression shall be of a boolean type" is a Legality rule, and not a Name
Resolution rule.  Thus, it appears that this is ambiguous and therefore illegal:

   procedure Proc (X : Boolean);
   procedure Proc (X : Integer);

   function Func (N : Integer) return Boolean;
   function Func (N : Integer) return Integer;

...

   Proc (if V1 /= V2 then Func(3));

even though there's only one legal interpretation, since the rule in
4.5.7(18) isn't considered for overload resolution.

I notice that in AI05-0147, there were several proposed versions of the Name
Resolution rules that included language like "If there is no ELSE part, this
type shall be a boolean type."  This seemed to get dropped out around January
2010.  Including a phrase like that would have made the above code legal.

Is the above code illegal?  Is that the intent?

(I don't have a preference one way or the other, and frankly I don't think this
situation will ever arise in the real world.  I just want to make sure I know
what's supposed to happen.)

***************************************************************

From: Tucker Taft
Sent: Wednesday, February 22, 2012  5:52 PM

> Is the above code illegal?  Is that the intent?

We generally try to avoid adding unnecessary complexity to overload resolution
rules.  So my view is that it is fine as is, where it is a legality check that
elseless-if- expressions have to be boolean.  But I don't have a strong opinion,
and perhaps the rule "drifted" into legality rules by mistake.  Randy would
probably know...

***************************************************************

From: Bob Duff
Sent: Wednesday, February 22, 2012  6:22 PM

...
> The rule in 4.5.7(18) "If there is no ELSE dependent_expression, the
> if_expression shall be of a boolean type" is a Legality rule, and not
> a Name Resolution rule.  Thus, it appears that this is ambiguous and
> therefore illegal:
>
>    procedure Proc (X : Boolean);
>    procedure Proc (X : Integer);
>
>    function Func (N : Integer) return Boolean;
>    function Func (N : Integer) return Integer;
>
> ...
>
>    Proc (if V1 /= V2 then Func(3));
>
> even though there's only one legal interpretation, since the rule in
> 4.5.7(18) isn't considered for overload resolution.

Yes, that sounds right.

> I notice that in AI05-0147, there were several proposed versions of
> the Name Resolution rules that included language like "If there is no
> ELSE part, this type shall be a boolean type."  This seemed to get
> dropped out around January 2010.  Including a phrase like that would
> have made the above code legal.
>
> Is the above code illegal?  Is that the intent?

Illegal.  And intended to be illegal, I think.

> (I don't have a preference one way or the other, and frankly I don't
> think this situation will ever arise in the real world.  I just want
> to make sure I know what's supposed to happen.)

I have a preference:  The Name Resolution rules shouldn't be "too smart".  That
is, they shouldn't make subtle distinctions, so if a human is likely to be
confused, then it's a good thing for it to be ambiguous, and therefore illegal.

We don't want someone thinking it might mean "else 0" in your example above.

***************************************************************

Questions? Ask the ACAA Technical Agent