Should compilers take advantage (abuse) of the new UDA syntax that has been accepted?

[Iain Buclaw]

On 18 December 2012 21:31, Andrei Alexandrescu <
SeeWebsiteForEmail at erdani.org> wrote:

> On 12/18/12 11:58 AM, Iain Buclaw wrote:
>
>> On 18 December 2012 16:43, Peter Alexander <peter.alexander.au at gmail.com
>> <mailto:peter.alexander.au@**gmail.com <peter.alexander.au at gmail.com>>>
>> wrote:
>>
>>     On Tuesday, 18 December 2012 at 15:19:58 UTC, Iain Buclaw wrote:
>>
>>         Should we take this as an opportunity for other compiler
>>         maintainers to implement their own compiler-specific predefined
>>         attributes?
>>
>>
>>     Please, no!
>>
>>     Suppose GDC implements @noreturn (or whatever other attribute)
>>
>>     Later, LDC implements @noreturn separately with slightly different
>>     semantics.
>>
>>     We now end up in a situation where @noreturn cannot be used
>>     portably, and neither compiler developer has incentive to change
>>     (whoever changes breaks their users code).
>>
>>
>> Provide a situation where @noreturn attribute would mean anything other
>> than telling the compiler to assume that the function|| cannot return,
>> and I might please you on *that* particular attribute.
>>
>
> One possibility: one compiler assumes @noreturn never returns, whereas
> another enforces that by adding an HLT at the end of the function.
>
> Andrei
>
>

The effect would really be the same though.  Typically in a @noreturn
function, there is no 'ret', so if the function were to return, the stack
would be left corrupt.  The key difference is that whilst in one program,
it halts at the point of the program that should never be reached.  The
other crashes an burns with a HLT or SEGV shortly afterwards.

This behaviour I describe incidentally is the case with assert(0) in
release code right now.  Different compilers handle it differently, DMD
just so happens to enforce that by adding a HTL at the end whilst others
don't.

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20121218/b73ba793/attachment.html>