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

I think that the main ROI here is that I believe there is
already implementation divergence in terms of how vendors
are dealing with "inout" defaults.  If we are going to
clarify that, particularly if we go along the lines of
how I responded to Shalom, it makes sense to deal with
"output" at the same time.  If we don't deal with this,
the implementation divergence will just become more
difficult to overcome in the future.

Gord.




Greg Jaxon wrote:
> 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.
>>
>>
>>
> 
> 

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


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