A new issue with IR 2099

EXAMPLE 5:

  package p1 is
    function "=" (a,b: ieee.std_logic_1164.std_logic ) return boolean;
    ...
  end package p1;

  package p_test is
    use work.p1.all;
    ...
    alias std_logic is ieee.std_logic_1164.std_logic;
    -- implicit "="
    -- alias "=" is ieee.stdlogic_1164."=" (a,b: std_logic) return boolean;
  end package p_test;

John Ries has raised an issue concerning this example.
His  question is:

Suppose in a declarative region you
    use p_test.all;

Which, if any, "=" operator for std_logic is visible?
It can't be the overloaded "=" from p1, since visibility isn't transitive
through packages. Is it the predefined "=" implicitly declared in package
p_test. If so, this is pretty weird, since the predefined "=" is not
visible in package p_test, by our proposal. If not, we need a rule to make
it not visible.

John has suggested the following modification to our proposed rules:

For aliases, the priorities are, in order:

1) explicitly declared aliases

2) implicitly declared aliases

3) potentially visible aliases, via USE clauses, whether explicit or
implicit.

A quick check of the other examples produce no changes in net results,
except for  EXAMPLE 5.

For EXAMPLE 5 the implicitly declared "=" associated with the alias
would be visible in the package p_test. Also, to answer John's question,
if you USED p_test you would see the same implicitly declared "=".

This new proposal is consistent with the current idea that potentially
visible declarations loose to declared declarations, even implicitly
declared ones (think of implicitly declared labels).

Here is my only problem with this new proposal:

In package numeric_std we have:

  type UNRESOLVED_UNSIGNED is array (NATURAL range <>) of STD_ULOGIC;
  function "=" (L, R: UNRESOLVED_UNSIGNED) return BOOLEAN;

Now suppose we write:

LIBRARY ieee;
USE ieee.numeric_std.ALL;
ENTITY e IS
...
ALIAS un_un is unresolved_unsigned; -- I prefer short names
...

If you did this then you wouldn't see the overloaded "=" from numeric_std,
but instead would get the predefined "=" operation.

On the other hand, this is exactly what the current LRM dictates, and
I don't know of any problems reported in this area.

What do you folks think about this issue?



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