> This is a long-overdue IR. I strongly support the proposed resolution.
>
> However, there are a couple of issues. 
>
> First, the proposal is not, strictly speaking, upward compatible.
>
> suppose you have two functions:
>
>     FUNCTION convert_int(x: integer) RETURN std_logic_vector;
>
> and
>
>     FUNCTION convert_int(x: integer) RETURN bit_vector;
>
>
> Under existing LRM rules the expression
>
>     IF(convert_int(5) = B"101")...
>
> is unambiguous. Under the new proposal it would be ambiguous.
> My feeling is that this is not sufficient reason to reject the
> proposal.

I agree.

> Second, the proposal does not address an important related problem.
> Under the current language rules, if you use a base
> specifier of O then the length of the string produced will always be
> a multiple of three. If you use a base specifier of
> X then the length of the string produced will always be a
> multiple of four. This is a great inconvenience for designers, who
> frequently need to specify bit strings which are not multiples of
> three or four, or who wish to use X notation (for readability) for strings
> of lengths which are not a multiple of four.
>
> One upward-compatible solution to this second problem is to allow
> an optional integer between the base_specifier and the bit_value
> string. This integer specifies the number of bits in the string.
> The details of just how to use this count remain to be worked out,
> but the idea is that if the string doesn't contain enough bits, then
> a '0' fill (on the left) will be done. If the string contains too many
> bits then left bits will be truncated, with an error if any of the
> truncated bits are '1'.
>
>
> E.G.
>
>     X7"7F" -- 7 bits of '1'
>
>
> What do you think?

An interesting idea, but one I find counter to the "spirit" ("corpse"?) of
VHDL.  I think that just concatenating on the extra bits needed is a feasible
solution (from the point of the user) that doesn't change the language any.  In
this way, the user can exactly control both the fill bits and the direction of
fill.  S/He can even use "(others => '0')" or something similar if the number
of fill bits is large (as long as the subtype doesn't need to be derived from
the concatenation, of course!)

--Paul