Re: [sv-bc] Mantis 1602: task/function default inout arguments

The big issue with default arguments is the binding environment to use
when interpreting the expressions.   For functions and tasks, this
ought to be quite tame: the names clearly resolve in the declarative
scope that defines the function or task.  For modules and other
instantiatable things, I know the committee has debated several alternatives.
I don't know off-hand how that debate was resolved, but it may impact
user expectations for function argument defaults.

I also can't judge ROI for this feature.  Are we talking committee
investment? - There it may be worth the exercise to make the edit and
specify one clean definition; the cost of not doing so is divergence
of our ever-fractious vendors. If we're speculating about vendors'
ROI for their higher cost of developing and testing a default output
feature, the outcome turns on what customers are willing to pay
for structured programming features like this.  I'd leave that to
the marketplace to sort out.

Greg

disclaimer: my humble opinions only...

Brad Pierce wrote:
> And the questions are -- should it be legal in SystemVerilog 2008 to
> declare default argument values for inout and output arguments of
> subroutines, and, if so, what should the semantics be? 
> 
> I think it wouldn't be good ROI to support such default argument values
> in SystemVerilog 2008, and, if SystemVerilog 2005 did not explicitly
> forbid such default arguments, then we should update the LRM to forbid
> them.
> 
> This feature could always be added in future revs of the standard.
> 
> -- Brad
> 
> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
> Bresticker, Shalom
> Sent: Tuesday, July 17, 2007 11:42 AM
> To: Greg Jaxon
> Cc: sv-bc@eda.org
> Subject: RE: [sv-bc] Mantis 1602: task/function default inout arguments
> 
> Greg,
> 
> But what do you (and Brad and everyone else) think about the questions
> on Mantis 1602?
> 
> Thanks,
> Shalom
> 
> --
> This message has been scanned for viruses and dangerous content by
> MailScanner, and is believed to be clean.
> 
> 
> 


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