RE: [sv-ec] Types, typedefs, and type parameters

1500 only exists now to correct wording errors found during the
discussions that led to dropping the request for the restriction. That
has been noted in the issue.

-----Original Message-----
From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org] On
Behalf Of Mark Hartoog
Sent: Tuesday, October 16, 2007 8:46 PM
To: Vreugdenhil, Gordon; SV_EC List
Subject: RE: [sv-ec] Types, typedefs, and type parameters

What is your position on forward typedefs? Are forward typedefs
a type with "first-class status"? 

The reason I ask is that in Mantis 1500 there was an attempt to
limit the use of forward typedefs so that they could only be
used to declare a class handle and for no other purpose. This
proposal was never approved by the BC committee, but it does 
appear to represent a decidedly second class type status for
forward typedefs.   



> -----Original Message-----
> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On 
> Behalf Of Gordon Vreugdenhil
> Sent: Tuesday, October 16, 2007 11:05 AM
> To: SV_EC List
> Subject: [sv-ec] Types, typedefs, and type parameters
> 
> There was some question in Monday's EC meeting as to what 
> Mentor was after in the type/typedef/type parameter space.
> 
> Mentor views all types as having the same first-class status 
> within SystemVerilog.  Essentially this means that we believe 
> that it is always valid to use a typedef or a type parameter 
> in a context in which a direct type reference is permitted.
> 
> So, for example, if you can extend a class type or construct 
> an object by using a direct class type identifier, you can 
> extend a type or construct an object by using a typedef or 
> type parameter that resolves to a class type.  The same 
> applies for all type-like contexts -- field declarations, 
> associative array index types, etc.
> 
> As with many language design principles, feature interaction 
> issues do show up as implementers apply principles to 
> functional systems.  These interaction issues need to be 
> resolved as specific issues without sacrificing language 
> principles and regularity.  Mentor agrees that there are a 
> few issues related to name resolution when adopting the 
> approach of all types as first-class; we've raised these few 
> specific issues in prior discussion and again in the name 
> resolution face-to-face.
> 
> Mentor believes that its approach to having all types treated 
> as first-class falls into the area of critical language 
> principles and as such, should not be unduly compromised.
> 
> Gord.
> --
> --------------------------------------------------------------------
> 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.
> 
> 

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



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