RE: [sv-ec] Proposal for Mantis 3001

Isn't this equivalent to

        Derived d = Base'(new());

Since a cast is defined to be equivalent to an assignment to an intermediate variable of the type being cast to?

-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Arturo Salz
Sent: Monday, September 12, 2011 2:17 AM
To: Jonathan Bromley; Vreugdenhil, Gordon
Cc: sv-ec@eda.org
Subject: RE: [sv-ec] Proposal for Mantis 3001

Jonathan,

I share some of Gordon's concerns. In fact, I believe it would be simpler to define this functionality strictly as a short-hand for not having to declare a temporary (extended type) variable and the corresponding cast. That is, given the following class hierarchy:

        class Base ; ... ; endclass
        class Derived extends Base; ... ; endclass

we allow:
        Base b = Derived::new();

As a shorthand for:
        Base b;
        Derived d = new();
        b = d;

    Arturo

-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Jonathan Bromley
Sent: Sunday, September 11, 2011 1:27 PM
To: Vreugdenhil, Gordon
Cc: sv-ec@eda.org
Subject: Re: [sv-ec] Proposal for Mantis 3001

Gord,

Point taken about the evaluation order concerns. I would be disappointed to lose the generality, but I would prefer the restriction you suggest, rather than not having typed constructors at all.

It was clear enough to me that, if a typed constructor were used in some general expression, its "construction" activity should take place before the expression saw its value. But I accept your concerns, and I'm willing to back-pedal in the way you suggest.

I don't really see a problem with ref arguments. Today you surely wouldn't expect to allow an arbitrary expression to appear as the actual for a ref-formal argument; there is a plausible interpretation (the reference is to a temporary variable that holds the expression's result) but it's not really useful, and current tools generally don't allow it even if the formal is "const ref". Similarly I wouldn't expect a typed-constructor to be legal in such context.

Ternaries are more tricky, I agree. Evaluation order then becomes a significant issue and I can see why you might not want to go there. We really don't want objects popping into existence in unexpected and/or indeterminate ways.

I'll upload a revised, restricted version before Monday's meeting.

Jonathan

On 11/09/2011 19:53, Vreugdenhil, Gordon wrote:
> Jonathan,
>
> I think that there are some fairly subtle issues that open up once you
> have object construction as a general expression. In particular, the issues of "referencing" might be a potential problem with, for example, ref arguments (is that even legal?). I'd have to think about issues related to "mid-expression" construction and reference in, say, ternaries and various other situations and what the implications on overall state might be (and whether they are always well defined in terms of order).
>
> I'd not be comfortable passing this as is right now without some deeper consideration which I won't have time to do until October due to travel commitments.
>
> If the context were restricted to the current forms (i.e. construction only as the immediate RHS of an assignment) I'd be more comfortable that implementations will end up doing the same thing.
>
> Gord.
>
> ________________________________________
> From: owner-sv-ec@eda.org [owner-sv-ec@eda.org] on behalf of Jonathan
> Bromley [jonathanbromley@ymail.com]
> Sent: Sunday, September 11, 2011 2:34 AM
> To: sv-ec@eda.org
> Subject: [sv-ec] Proposal for Mantis 3001
>
> hi EC,
>
> I've uploaded what I hope is a complete proposal for Mantis 3001.
> It's fairly simple and I think there was some consensus in an earlier
> discussion that "base=Derived::new();" makes sense.
> It would be nice to put this to bed if there's agreement.
>
> Jonathan Bromley
>
> --
> 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.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.