Re: [sv-ec] Proposal for Mantis 3001

On 12/09/2011 07:17, Arturo Salz wrote:
> 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.

Arturo,

Yes, if the construct is restricted to be used only in the same place a
constructor goes now, then that's exactly right. I don't think it's
helpful to use that as the LRM definition, because there are too many
syntactic wrinkles so it can't be a simple rewriting rule. But it
should go in as an explanatory note.

Thanks

Jonathan

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