Re: [sv-ec] Proposal for Mantis 3001

Steven

I guess you meant

   Base b = Derived'(new());

and I can't find any tool that supports this syntax. But I agree it
sounds reasonable, and meets the need without creating any novel
syntax. It would, though, require some juggling of the BNF to permit
this, since new() isn't a primary. Furthermore, I don't think the
current syntax for casting_type permits parameter specializations, which
would be tiresome since it would force you into a typedef for
parameter-specialized derived classes.

I'll redo the proposal on this basis if people prefer it, but it would
be quite disruptive to the BNF whereas the current (version 2) proposal
has really small impact there.

Jonathan

On 12/09/2011 14:44, Steven Sharp wrote:
> 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.