IEEE 200x Fast Track Change Proposal

ID:             FT-26

Proposer:       Chuck Swart (cswart@model.com)
Analyzed by:

Status:         Open
Proposed:       23-Mar-2003
Analyzed:       Date
Resolved:       Date

Enhancement Summary: Relax restrictions on qualified expressions and
return values from functions
Related issues:
Relevant LRM sections: 7.3.4 Qualified expressions, 8.12 Return Statement


----------------------
Enhancement Detail:
----------------------

1) Qualified expressions, which are used to determine the base type of
potentially ambiguous expressions, require that the value of the
disambiguated expression belong the the subtype. The subtype check is
unduly restrictive and, in some cases, can only be resolved by using a
complicated expression involving both a qualified expression and a
type conversion. This situation is especially prevalent in case
expressions involving arrays.

Consider the following example:

    SUBTYPE bv87 is bit_vector(8 downto 7);
    ...
    CASE bv87(bit_vector'('0'&'1')) IS
    
        WHEN "00" => ...

The qualified expression, bit_vector' is needed because the
concatenation could be for bit_vectors, strings, std_logic_vectors,
etc. The type conversion is currently needed because the concatenated
expression has index values 0 and 1 instead of the desired 8 and 7.

Many users of VHDL find case expressions like this confusing and
overly verbose.

If we change the semantics of a qualified expression to perform a type
conversion instead of subtype check then expressions like those above
become simpler and more intuitive:

    case bv87'('0'&'1')is...

Also note that FT25 relaxes the requirements on case expressions. Even
so, the proposed change to qualified expressions is a step in the
direction of relaxing burdensome requirements without breaking strong
typing.

2)Currently VHDL requires that the return expression match the
corresponding result subtype. For arrays, this means that both the
bounds (and possibly the direction) of the expression must agree
exactly with those of the result subtype.

This rule is also too restrictive. Instead, subtype matching on return
expressions should be treated similarly to existing rules on signal
and variable assignments.

----------------------
Relevant LRM sections:
----------------------

7.3.4

Replace  the last sentence before the Note with:

"The evaluation of a qualified expression evaluates the operand and
converts it to the subtype denoted by the type mark."

8.12

The paragraph starting "For the execution..." should be rewritten as follows:

"For the execution of a return statement, the expression (if any) is
first evaluated and converted to the result subtype. The execution of
the return statement is thereby completed if the conversion succeeds;
so also is the execution of the enclosing subprogram. An error occurs
at the place of the return statement if the conversion fails."

---------
Analysis:
---------


-----------------------
Recommendations
-----------------------