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

Unconnected ports to an instance always have a corresponding vacant
position in the port list - a position delimited by commas or parentheses.
Although this doesn't make much visual impact, it is still a
noticeable anomaly as you scan source code.

Default arguments (ports) do not require a vacant placeholder.
The whole point is to allow the API to grow under a legacy
user base.  The difference is slight, but significant enough
to support actual differences in behavior.

I'm less sure than Gord that silently allowing outputs to be
unassociated is a Bad Thing.  I suppose the API designer could
take on that choice, by whether or not he specified a default
sink for the output.  If the output line is optional (e.g. a generic
adder would let you either take or leave off the carry bit),
the supplier of that subroutine typically knows this.  If the
output (or any argument) has no default, then it must have a
corresponding placeholder at every call site.  If a placeholder
is left vacant, this is a case where the /user/ of the API
has made a choice to present a default source or sink.

I always assume a "contract" model for call sites: I like to see
the caller and the library have equal negotiating power over the
contract.

As to protection from user-error, I think the only error cases here
are failures of correspondence between argument lists.  This includes
having no call-site placeholder for an argument with no default expression.
Also misspelling named ports, or mixing named and positional incorrectly.

Greg


Jonathan Bromley wrote:
>>> GORD:  I almost certainly oppose silently allowing outputs to 
>>> be unassociated.
>> [SB] Verilog has always had implicitly unconnected module 
>> ports, though.
>> Just omit them from the port connection list.
> 
> Despite the syntactic similarities, I don't think it's right to
> decide what subprograms should or shouldn't do by appealing to 
> what modules do.  For example, we don't expect modules to act 
> the same way as subprograms when their formals and actuals
> have differing vector widths.
> 
> Personally, I would prefer to keep the rules as simple as 
> possible, and forbid any defaults on anything other than 
> inputs.  I say that because there's still a little part of
> me that dreams of subprograms (or, at least, class methods)
> overloaded by argument signature; and I suspect that fancy
> defaults will interact in hard-to-predict ways with any 
> future enhancements for overloading.


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