>From: Gordon Vreugdenhil <gordonv@model.com> >>> 2. What if "nonvoid function" or "non-void function method" is called >>> like a task - return value is discarded >> >> Technically, the LRM defines it by what you are calling, not by how it is >> called. However, the same reasoning applies here as in the void function >> case, so I don't see a reason it could not be allowed. > > >Steven, the reason that was not allowed (intentionally!) was for >things like vcd related systf routines which for historical reasons >allowed task/function scope names as args. If you then had a >bare function name you would either have to make an explicit >exception for those routines or have legacy compatibility issues. Another problem was identifiers in port expressions that had no declaration in the local scope. It would not be clear whether this was a no-parentheses function call that needed to be resolved hierarchically, or an implicitly declared net. I believe you were the one who pointed out this issue. There were a number of ambiguous situations if this were allowed, which is what I said. But these only applied when the identifier appeared in an expression context. In a statement context, these were not a problem, regardless of whether the identifier was a task, or a non-void function being called like a task. Steven Sharp sharp@cadence.com -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Fri Jun 19 11:46:37 2009
This archive was generated by hypermail 2.1.8 : Fri Jun 19 2009 - 11:47:27 PDT