RE: [sv-bc] Mantis 1602: task/function inout arg defaults - draft proposal

Hi Shalom,

 

This still does not explain when the default expression is applied to an
output, or why you would want to use one. If the only purpose is to
leave the output unconnected, why don't we use something like

 

output/inout int arg = null; 

 

to say that the output may be discarded if left unconnected.

 

We probably should only allow const ref arguments, not ref arguments to
specify a default.

 

I liked the original wording about the default expression being bound to
the declaration scope. I don't like words like "as though" to describe
behavior.

 

________________________________

From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On
Behalf Of Bresticker, Shalom
Sent: Tuesday, August 14, 2007 10:44 PM
To: sv-bc
Subject: FW: [sv-bc] Mantis 1602: task/function inout arg defaults -
draft proposal

 

Hi,

 

I did not get any responses to this.

 

Please comment.

 

Thanks,

Shalom

 

________________________________

From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On
Behalf Of Bresticker, Shalom
Sent: Friday, August 03, 2007 6:29 PM
To: sv-bc
Subject: [sv-bc] Mantis 1602: task/function inout arg defaults - draft
proposal

<<1602_D3a.doc>> 
Hi, 

I have attached a draft proposal for Mantis 1602, clarifying the
behavior of subroutine inout argument defaults and also allowing output
defaults. It still does not cover allowing output arguments to be
unconnected. Please comment.

The phrasing about identifiers in the defaults being bound from the
scope of the subroutine declaration is the same as the original
phrasing, but I feel it is not clear enough and requires some examples
to clarify it.

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. 


-- 
This message has been scanned for viruses and 
dangerous content by MailScanner <http://www.mailscanner.info/> , and is

believed to be clean. 

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