(j3.2006) J3/12-nnn J3 interpretations letter ballot #26 aftermeeting 198

[Van Snyder]

On Fri, 2012-09-14 at 14:19 +0900, Malcolm Cohen wrote:
> Nick Maclaren writes:

> >I think that the decisions to allow arbitrary expressions in both
> >locations should be reconsidered in the next revision.  I would favour
> >deprecating any expression other than a designator or function
> >reference.  There is precedent in the handling of assumed-length
> >function results.
...
> The problems here are that we got the syntax badly wrong.  It is not entirely 
> unreasonable to make a "bigger than the absolutely minimal" change to the syntax 
> to fix the problem, especially since it could be argued that the minimal change 
> is hard to understand and also encourages programs with very confusing syntax; 
> this is hardly "encouraging program reliability".  But if we think that the 
> minimal change is the correct fix now, we should commit to supporting that in 
> the future, and not nibble at the edges in a later revision.

One of the repairs I suggested (at the end of 12-149 and 12-150) was to
apologize for allowing operator syntax to access L-value functions, and
disallow it.  From the end of 12-149 (or 12-150):

        That this program is ambiguous was caused by an oversight to
        allow a
        <variable> to consist of <expr>, in which <expr> is a reference,
        as a defined operation, to a function that has a data pointer
        result.
        
        Replace R602 and C602 in subclause 6.2 by
        
        R602 <variable> <<is>> <designator>
                        <<or>> <function-reference>
        
        C602 (R602) <function-reference> shall be a reference to a
        function that has a data pointer result.

This would answer both F08/0075 and F08/0076.

As Malcolm points out, if we want to do it, we need to do it now, not
after vendors start implementing the use of operator syntax, and users
start using it.