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

The ROI I was talking about was committee time, considering that there
are currently 64 other open SV-BC errata and 31 open V-1364 errata that,
like 1602, are marked Severity=Major.

When confronted with an unclear spec for a feature, a reasonable option
to consider is pruning the feature.

-- Brad
   

-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Greg
Jaxon
Sent: Tuesday, July 17, 2007 4:29 PM
To: sv-bc@eda.org
Subject: 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.


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