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

Some thinking out loud: 

I don't have firm opinions about most of these, either, so the following
are thrown out for discussion.

> And the next time they call, they
> want the same default value as last time, not the value that
> got left in that shared place by the previous call.

Not quite. Since the default can be an expression, then even if you
treat it as in input, its value can change between task calls.

--

> (For a ref arg, there
> seems to be no choice but for the default to be a valid reference.)

I understand you to mean that a ref argument would have to be treated
that way even as a default. If so, it might be inconsistent to treat an
inout default differently than an explicit inout argument.

--

> When you leave off an output, you want the output discarded.

While you can leave off a module output, I don't think you can leave off
a task/function output.

-- 

> When you leave off an input, you want a default value. When
> you leave off an output, you want the output discarded. So
> when you leave off an inout, you probably want a default value
> for the input, and the output discarded.

One thing I discovered about inout module ports only last year is that
you can't connect them to a constant. I think the particular case was of
an inout that was not actually being written to. It's obvious once you
think about it, of course. If you have declared it as an inout, that is
a statement of intent that you want it to be writable. 

I assume the same is true of task and function inouts. 

Until now, there was no suggestion that a default be treated differently
than an explicit argument. If you do, then an inout default could be a
constant as well as an expression.

On the other hand, if you say that an inout default is like an explicit
inout argument and there is copy-out at the task end to the default
expression, then it might also be logical to allow defaults for outputs.

If you oppose defaults for outputs, and I admit I am not sure about the
idea, then defaults for inouts or ref arguments also sounds like a bad
idea.

Shalom


> -----Original Message-----
> From: Steven Sharp [mailto:sharp@cadence.com]
> Sent: Tuesday, September 19, 2006 1:27 AM
> To: sharp@cadence.com; gordonv@model.com
> Cc: sv-bc@eda-stds.org; Bresticker, Shalom
> Subject: Re: [sv-bc] task/function inout arguments with default values
> 
> 
> >From: Gordon Vreugdenhil <gordonv@model.com>
> 
> >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?
> 
> I am not suggesting that it be treated as an input only if
> it was assignable.  I am suggesting that the default always
> be treated as an input only, regardless of whether it is
> assignable or is assignment compatible.  So the issue you
> raise does not come up.
> 
> I think that if someone leaves out an inout argument, they
> generally want the output discarded, not stored in some place
> used by all the callers.  And the next time they call, they
> want the same default value as last time, not the value that
> got left in that shared place by the previous call.
> 
> When you leave off an input, you want a default value.  When
> you leave off an output, you want the output discarded.  So
> when you leave off an inout, you probably want a default value
> for the input, and the output discarded.  (For a ref arg, there
> seems to be no choice but for the default to be a valid reference.)
> 
> This just seems to me to be more useful than the alternative.
> Some input from users would be helpful here, since I could be
> wrong about this.
> 
> Steven Sharp
> sharp@cadence.com