RE: [sv-ec]E-mail Vote (part 1) 1384

See below. 

-Dave.

> -----Original Message-----
> From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org]
On
> Behalf Of Neil Korpusik
> Sent: Saturday, April 21, 2007 4:33 PM
> To: Mehdi Mohtashemi
> Cc: sv-ec@server.eda.org
> Subject: Re: [sv-ec]E-mail Vote (part 1) Closes 12am PST April 24th
> 
> 1384  ___ Yes   _X_ No
> 
>    Sub-clause 4.16 Bit-stream casting, the following text has been
added
> 
>       An associative array or class shall be illegal as a destination
> type. A
>       class handle with local or protected members shall be illegal as
a
> source
>       type except when the handle is the current instance this. (See
7.10
> and
>       7.17).
> 
>    a. If these restrictions are added, they should be placed earlier
in
> this
>       sub-clause. The text that comes earlier in this sub-clause is
> written
>       as though these restrictions don't exist.


[DR>] I didn't want to put this restriction in until after source and
destination types had been explained. If I move it up, then we'll have
the opposite problem. But if other people thing your way would be
clearer overall, I'll be happy to change it,

> 
>    b. I don't see the need for part of the first restriction
> 
>          An associative array or class shall be illegal as a
destination
> type.
> 
>       Why are classes not allowed as a destination type? Null handles
> shouldn't
>       be allowed, but why not a handle that refers to an instantiated
> object?
[DR>] Because the result of the cast to a class type would have to be a
constructed handle. The target is not the LHS of an assignment; the
target is a temp variable of the target type. A clearer illustration of
this problem is when calling an automatic function that has a class
argument.

class c;
classA m_A;
function void foo(classA A);
  m_A =A;
endfunction
endclass

Now the call to that function tries to cast its argument to a classA
type:

foo(classA'(expr));

Since the cast occurs before the actual function call and bit-stream
casting cannot construct class objects, there's no way to pass an object
handle to that function foo.


> 
>       If classes are allowed as a destination type, the following
should
> be
>       added to 4.16.
> 
>          Reconstruction does not modify any internal properties in the
> target
>          class object.
> 
> 
> 
> Mehdi Mohtashemi wrote On 04/17/07 15:21,:
> >
> > Based on April 16th, 2007 sv-ec meeting, we are conducting an
> > email vote on the following mantis items.
> > 1655, 1732, 1777, 1371, 1384, 1707, 1680, 1427, 1723, 1736.
> > Part 2 of email vote will start next week.
> >
> > Please note that the operating guidelines are:
> > - Only one (1) week to respond (Midnight April 24th 2007)
> > - An issue passes if there are zero ** NO ** votes and at least
> >   half of the eligible voters respond with a YES vote.
> > - Any NO vote must be accompanied by a reason.
> >   This issue will then be up for discussion at the
> >   next conference call.
> >
> > As of the April 16th meeting, the eligible voters are (total 11):
> >
> > Arturo Salz,
> > Cliff Cummings
> > Dave Rich
> > Don Mills
> > Doug Warmke
> > Heath Chambers
> > Mark Hartoog
> > Michael Mintz
> > Neil Korpusik
> > Ray Ryan
> > Stu Sutherland
> >
> > Please mark your vote below by an x. If No, then specify a reason.
> > Send it to the reflector.
> >
> > 1655  ___ Yes   ___ No
> > 1732  ___ Yes   ___ No
> > 1777  ___ Yes   ___ No
> > 1371  ___ Yes   ___ No
> > 1384  ___ Yes   ___ No
> > 1707  ___ Yes   ___ No
> > 1680  ___ Yes   ___ No
> > 1427  ___ Yes   ___ No
> > 1723  ___ Yes   ___ No
> > 1736  ___ Yes   ___ No
> >
> 
> 
> --
> 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.