Re: [sv-bc] task/function inout arguments with default values

I don't think that I like this idea.  The problem is that
assignment compatibility (copy-in/copy-out) is assymetric.
If you had, for example, an non-assignable default expression,
then it might be Ok to treat it as just an "in".  However,
if the default was assignable but the assignment compatibility
on the "out" direction was violated would one treat the
default as an "in" or produce an error?

It seems that this is likely to be pretty subtle.  I'd rather
require that "inout" with a default mean that the default
is treated as a normal inout -- it must be assignable and
compatible in both directions.

Gord.


Steven Sharp wrote:

>>From: "Bresticker, Shalom" <shalom.bresticker@intel.com>
> 
> 
>>This does not seem quite correct for inouts. For inouts, the actual
>>argument needs to be an expression which is valid on the left-hand side
>>of a procedural assignment (1364-2005, 10.2.2).
> 
> 
> There is another possible way that it could work.  You could consider
> that by leaving off the explicit argument value, the user is saying
> that they don't care about the value coming back.  They still need to
> provide an input value, for the copy-in.  But the copy-out would not
> be done.  Therefore the default value expression would not need to be
> an lvalue.  Putting it another way, when using the default value for
> an inout, it would be treated like an input.
> 
> I don't know if that is what was intended.  It seems reasonable, and
> more usable than a default that must be an lvalue.  If that was the 
> intent, then it needs to say so.
> 
> Steven Sharp
> sharp@cadence.com
> 
> 

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com