Re: [sv-ac] 928 Proposal Updated

Hi Ed:

I think that sequence, property, and void arguments, as well
as untyped, are passed by substitution.

For other typed arguments, I think that we need to use the 
current LRM mechanism, which applies the assignement rules.
I think of this like having an implicit wire for the formal
argument in the declared sequence or property and assigning
the actual argument expression to that wire.  As a result, 
the assignment rules for type coercion are used (e.g., truncation,
padding).  If the type of the actual argument expression cannot 
be coerced to the type of the formal argument, then the compiler
should reject the code.

Is this what you have in mind?

J.H.

> X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
> Content-class: urn:content-classes:message
> Date: Wed, 28 Jun 2006 14:15:30 -0700
> Thread-Topic: [sv-ac] 928 Proposal Updated
> Thread-Index: Acaaq6WsLvdJK0zbS2C0VCj1KFg/3wAQrspA
> From: "Eduard Cerny" <Eduard.Cerny@synopsys.com>
> Cc: <Bassam.Tabbara@synopsys.com>, <Eduard.Cerny@synopsys.com>,
>         <dmitry.korchemny@intel.com>, <Brad.Pierce@synopsys.com>,
>         <sv-ac@eda-stds.org>
> X-OriginalArrivalTime: 28 Jun 2006 21:15:31.0187 (UTC) FILETIME=[FC952430:01C69AF7]
> 
> Hi,
> 
> It seems to me that the definition of what is const, pass by value, pass
> by substitution and pass by reference (isn't that the same as
> substitution?) will make it quite complicated. Yet, pass by value will
> anyway introduce a local variable, but implicitly. Perhaps that could be
> left to the user - explicit user-defined local var if by value is
> needed. Therefore, adding sequence, property and void as a type (in
> addition to untyped with the restriction that is already in the
> proposal) might be ok. All is still passed by substitution, the types
> are only used to make sure that a type error is not detected only once
> the actual arg is substituted in the use context.
> 
> so... leaving aside the 3 new types, it seems to me that the proposal as
> it stands now on Mantis is sufficient... and I'd vote yes for that
> one...
> 
> ed
>