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

My comments below with "GORD:".

Bresticker, Shalom wrote:
> Hi,
> 
> Section 13.5.3 in Draft 3a describes task/function default arguments.
> Mantis 1602 describes ambiguity with respect to inout defaults.
> Many questions and possibilities arose during the discussion of this and 
> I would like to get the feeling of the committee with respect to the 
> desired resolution.
> 
> See Mantis 1602 for a full discussion of the issues.
> 
> Answering the following questions will clarify the desired resolution.
> 
> Normally, inout arguments are copy-in at the beginning of execution of 
> the call and copy-out at the end. So a regular inout argument needs to 
> be legal as an lvalue (left-hand side of a procedural assignment).
> 
> 1. Should a default inout argument behave the same as a regular inout 
> argument?


GORD: Yes.  The LRM text should be modified to say "expression"
GORD: rather that "value".


> That would mean it would have to be a legal lvalue and the value would 
> be copied out to the default argument at the end of the call.
> 
> It would mean also that the following text is not precise:
> "When the subroutine is called, arguments with default values can be 
> omitted from the call, and the compiler shall insert their corresponding 
> values."
> 
> That text would work for the copy-in at the beginning, but not for the 
> copy-out at the end. For the copy-out, the compiler would need to insert 
> the default expression itself, not its value.
> 
> Also, since "The expression is evaluated in the scope containing the 
> subroutine declaration each time a call using the default is made,"
> 
> the copy-out expression would be bound to the declaration scope, not to 
> the scope of the call.
> 
> In the case of a static routine, it would also preserve its value 
> between calls.
> 
> 
> 2. Should a default inout argument be treated like an input argument? 
> (After all, outputs *currently* cannot have defaults.)

> 2a. Should there be only copy-in at the beginning, but no copy-end at 
> the end?
> 2b. Should a default inout argument be allowed to be any legal input 
> expression, including a constant, and need not be a legal lvalue?
> 
> 2c. Do you favor only 2a, but not 2b?


GORD:  As stated in (1), I prefer just "expression use".  If follows
GORD:  that I think that defaults should be allowed for output as
GORD:  well.

GORD:  If inout ends up being treated as "only copy-in for defaults"
GORD:  then I'd prefer 2b. to be symmetric with input.  But this
GORD:  is definitely not my preference.


> 
> 3. What about a ref argument default? Does it have to be a (pointer to 
> a) valid lvalue?

GORD:  Definitely yes.  I would oppose any other answer on this one.



> 4. Should you be able to leave off an output argument? That presumably 
> means simply discarding the output value. (Mantis 1600)

GORD:  I strongly prefer allowing defaults for outputs.  Silently ignoring
GORD:  an output is very dangerous as far as I am concerned since
GORD:  the addition of a *non-defaulted* output could be missed in
GORD:  calling code.  If we allow explicit defaults, then there is
GORD:  a direct mechanism for a user to add a "sink" themselves and
GORD:  ensure that outputs are only ignored when they want them to
GORD:  be.  If we allow defaults to be skipped, I'll be that we end
GORD:  up adding something like "default_output_formals none" or
GORD:  similar to have a standard mechanism for disallowing such code.

GORD:  I almost certainly oppose silently allowing outputs to be unassociated.



> 5. Should you be able to specify an output default?  If you answer 'yes' 
> to question 1, then maybe you would favor this as well, with the same 
> behavior as in question 1, because an inout is a combination of an input 
> and an output.

GORD:  Yes; see other comments above.



> 6. If you answered 'yes' to question 2 or 4, then what about the formal 
> argument connected to a defaulted inout or an unconnected output in a 
> static routine? Should it be treated like any other internal variable of 
> the routine, retaining its value between calls?


GORD:  A static routine's formals are always persistent.  So even
GORD:  for an "input", one can hierarchically assign to them.  The
GORD:  LRM only says that copy-out does not occur for an input and that
GORD:  copy-in doesn't occur for an output.

GORD:  The bigger question is the latter part -- if one permits unconnected
GORD:  outputs (which I oppose), I assume that the rules would need to
GORD:  say that *no* value assignment is done on entry and no copy-out is done
GORD:  at exit.  So the output would retain its value from the previous
GORD:  call and, if modified, the new value would be retained (even though
GORD:  it isn't written out).



> 7. Do you favor removing defaults from inout arguments altogether?


GORD:  My first preference is to have "expression" use and require
GORD:  writable defaults.  As alternatives, I'm roughly equally willing to
GORD:  accept disallowing defaults or to accept "copy-in only" semantics.

> 
> 8. Do you favor removing defaults from ref arguments altogether?


GORD:  No.  Allowing ref defaults is pretty useful for classes where
GORD:  you want methods to have defaults that are data structure "collections"
GORD:  that are written to if the user does not provide a collection.



Gord.




> If there is a clear consensus in a certain direction, then we can write 
> a proposal for it. Currently, we don't yet know what direction to go in.
> 
> Thanks,
> Shalom
> 
> Shalom Bresticker
> Intel Jerusalem LAD DA
> +972 2 589-6852
> +972 54 721-1033
> 
> 
> -- 
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, 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.