Re: [sv-ec] Two simple proposals for discussion

Alex

Fair comment. Instinctively (and thoughtlessly) I'd say "a run-time check"
but "a check performed at runtime". But I really have no idea why that
sounds right to me. I'll take care to deal with it in one of the inevitable
future edits.

Jonathan

On Mon, Feb 21, 2011 at 10:56 PM, Gran, Alex <alex_gran@mentor.com> wrote:

> Nit-picky formatting thing:
>
> 3293 proposal:
> Last paragraph of 8.15 "may issue a warning before runtime"
> In the Note below 8.15 "is a run-time check"
>
> Should "runtime" either be either hyphenated or not, but the same in
> both places?
> It appears that both 'runtime' and 'run-time' are used elsewhere in the
> LRM, but 'run-time' is more common
>
> ~Alex
>
> -----Original Message-----
> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
> Jonathan Bromley
> Sent: Monday, February 21, 2011 2:12 PM
> To: sv-ec@eda.org
> Subject: [sv-ec] Two simple proposals for discussion
>
> I've uploaded "draft A" proposals for 3001 and 3293. Please take a
> look.
>
> Possible issues that you may wish to review:
>
> - 3001:
> I've settled for the "D::new" syntax for calling D's constructor, simply
>
> because I like it better than "new D" which has a lexical ambiguity with
>
> the copy constructor (and yes, I know it's an ambiguity that's
> relatively easily resolved by tools, but I'm less sure about humans).
> I've also sidestepped the task of writing BNF productions, until we get
> consensus.
>
> - 3293:
> Tools currently differ in how they handle $cast when the source
> expression is null. I've gone for making that unconditionally a
> failure. I know that a literal null could reasonably be cast to any
> class type, but I don't think a literal null is very useful as the
> source expression for $cast so I preferred to avoid creating a special
> case. I am pretty certain that it's correct to fail on any other null
> expression, although not all tools currently agree with me.
> I've tried to rewrite the text to be clearer, more consistent with the
> rest of the LRM and less likely to need revision when interface classes
> arrive. And I've dropped the mention of "singular" in the quasi-syntax
> examples, because I couldn't see for the life of me what usefulness or
> clarification it might bring.
> I would have preferred to see the non-value-returning version of $cast
> be specified as "function void" because it's not time-consuming, but
> that would have made it inconsistent with many other system tasks.
> The list of things in 10.8 (Assignment-like contexs) that are NOT
> assignment-like contexts mysteriously mentions static casts but not
> $cast, so I thought it prudent to mention that in the proposal.
>
> Thanks
>
> 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.