Re: [sv-ec] Default paramerized class type syntax

From: Gordon Vreugdenhil <gordonv_at_.....>
Date: Thu Apr 05 2007 - 14:20:05 PDT
Yup, that was about a year ago when there wasn't nearly
as much code around as now.  Although I would have
liked to have made things explicit, I'm not sure I would
support that anymore.  The issues regarding function
return scoping now have other (better) solutions than I had
in mind then as well.

Gord.

Brad Pierce wrote:
> See also --
> 
>    http://www.eda-stds.org/sv-ec/hm/3386.html
> 
> -- Brad 
> 
> -----Original Message-----
> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
> Gordon Vreugdenhil
> Sent: Thursday, April 05, 2007 1:51 PM
> To: Francoise Martinolle
> Cc: sv-ec@eda-stds.org
> Subject: Re: [sv-ec] Default paramerized class type syntax
> 
> 
> 
> Francoise Martinolle wrote:
>> Have we decided whether or not the
>> class declaration name itself can represent the specialization 
>> datatype of a parameterized class?
>>  
>> For example:
>> class C #( parameter p = 0);
>> endclass
>>  
>>  
>> C #() myv; // I think that this is legal according to the BNF
>> C myv;     //  but is this legal too?
>>  
> 
> The LRM is pretty clear that references to the parameterized class name
> cause a default specialization.  The only circumstances where this isn't
> the case is the syntax that I still owe for class_name::function (or
> task) and the class_name::method_name syntax for extern methods.
> 
> So both "C myv" and "C#() myv" would be legal and would have identical
> semantics.
> 
> 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.
Received on Thu Apr 5 14:20:18 2007

This archive was generated by hypermail 2.1.8 : Thu Apr 05 2007 - 14:20:31 PDT