Re: [sv-ec] Mantis 2606 - type name resolution in out-of-block method prototypes

Francoise,

I specifically did not want the "as if at the end" rule in
place since that adds substantial bias to a question that
Mark and Steven both raised.  If we have:

   class c;
      typedef  int T;
      extern task tf;
   endclass

   int b;
   task tf;
     int y = b;
   endtask

The point that Mark and Steven made was that they want "b" to
be legal to use in tf.  Any "as if at the end" semantics would
(at very least) imply that such a reference is illegal.

Writing up full wording (and integrating that in other places)
to cover this aspect along with my proposal would be more work
than I have time to do.  As a result I intentionally used the more
ambiguous wording so that the question is left open.

I don't know if the wording of "out-of-block method declaration"
caused confusion in the first sentence -- that was intended
to be the entire method, not just the "header" as for the
error condition.  I certainly expected that the body's use
of "T" in your example would resolve to the class "T" since
that is visible.  I didn't explicitly say that the class
stuff was "first" in the lookup alg, but since that is the
normal order for a method and I didn't contradict that with
my write-up, I think it is reasonable to assume that order.

In short -- I would like to stay away from any "as if at the
end" kind of rule.  Barring that kind of language, if you
have other suggestions, we should certainly talk about that.

Gord.



Francoise Martinolle wrote:
>  
> 
> I read the proposal. I am not clear as how  to resolve an identifier
> found 
> in the method body, should one first try to resolve the identifier in
> the class declaration, then if not found, 
> follow the normal simple name resolution rules.
> I think it can be interpreted that way but perhaps we should be more
> precise and say that.
> 
>>From the proposal, I cannot determine which T the following example
> resolves to:
> 
> class c;
> typedef  int T;
> extern task tf;
> 
> endclass
> 
> typedef real T;
> 
> task tf;
>   T arg1;
>   begin
>   end
> endtask
> 
> Rather than saying that the Out of block method declaration has access
> to class properties and types 
> I would prefer saying that resolving identifier in the the method body
> is as if the method body was placed at the end of the class declaration.
> Consequently any declaration between the endclass
> and the task method body has no effect.
> 
> Francoise
>     '
> -----Original Message-----
> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
> Gordon Vreugdenhil
> Sent: Monday, June 08, 2009 5:11 PM
> To: SV_EC List
> Subject: [sv-ec] Mantis 2606 - type name resolution in out-of-block
> method prototypes
> 
> I've uploaded a proposal for 2606 (in Word and pdf) that addresses the
> direct ballot question.  It doesn't address a couple of the other issues
> raised in the meeting today but is likely as much as we can do for this
> PAR.  I think this captures the consensus at least in intent.
> 
> I am not available from June 10-16 so someone else can pick up the word
> doc and make any additional changes if this isn't adequate.
> 
> Gord.
> --
> --------------------------------------------------------------------
> Gordon Vreugdenhil                                503-685-0808
> Model Technology (Mentor Graphics)                gordonv@model.com
> 
> 

-- 
--------------------------------------------------------------------
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.