www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Should compilers take advantage (abuse) of the new UDA syntax that has

reply "Iain Buclaw" <ibuclaw ubuntu.com> writes:
Now that UDA's have extended their support to  attribute

https://github.com/D-Programming-Language/dmd/commit/0814f9decfdbcef644c4e89b02b8be192ed2e900


Should we take this as an opportunity for other compiler 
maintainers to implement their own compiler-specific predefined 
attributes?


Example:

Where GDC has the following to allow developers to mark functions 
with the backend attribute 'noreturn'.

pragma(attribute, noreturn)
void die()
{
    abort();
}


Potentially this can now be re-written as.

void die()  noreturn
{
    abort();
}


Would you guys stand for such a change to be allowed?

Thanks,
Iain.
Dec 18 2012
next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 18 December 2012 15:19, Iain Buclaw <ibuclaw ubuntu.com> wrote:


 Potentially this can now be re-written as.

 void die()  noreturn
 {
    abort();
 }


By the way, this would be the first time that  noreturn has been brought up.

http://forum.dlang.org/thread/i9p9li$282u$1 digitalmars.com


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Dec 18 2012
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 18 December 2012 15:24, Iain Buclaw <ibuclaw ubuntu.com> wrote:


 On 18 December 2012 15:19, Iain Buclaw <ibuclaw ubuntu.com> wrote:


 Potentially this can now be re-written as.

 void die()  noreturn
 {
    abort();
 }


 By the way, this would be the first time that  noreturn has been brought
 up.


s/would/wouldn't/

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Dec 18 2012
prev sibling next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
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?


I think it'd be great if we used magical full names, but 
otherwise it is the same as the library. Then they are namespaced 
and can be shared.

module core.gdc;
struct noreturn {}
// and whatever


Then when you use it, you import core.gdc and use  noreturn. The 
compiler doesn't define the attribute, but it recognizes the full 
name of core.gdc.noreturn and gives it special treatment like an 
intrinsic.
Dec 18 2012
parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 18 December 2012 15:29, Adam D. Ruppe <destructionator 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?


 I think it'd be great if we used magical full names, but otherwise it is
 the same as the library. Then they are namespaced and can be shared.

 module core.gdc;
 struct noreturn {}
 // and whatever


 Then when you use it, you import core.gdc and use  noreturn. The compiler
 doesn't define the attribute, but it recognizes the full name of
 core.gdc.noreturn and gives it special treatment like an intrinsic.


If doing it that way, it would be better to store all predefined attributes
into a binary tree.

UserAttributeDeclaration::addPredefinedAttribute("property");  // etc


And have a magical empty module, gcc.attributes, which when imported
injects the compiler-specific attributes.

UserAttributeDeclaration::addPredefinedAttribute("noreturn");  // etc


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Dec 18 2012
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Iain Buclaw:


 Where GDC has the following to allow developers to mark 
 functions with the backend attribute 'noreturn'.

 pragma(attribute, noreturn)
 void die()
 {
    abort();
 }


 Potentially this can now be re-written as.

 void die()  noreturn
 {
    abort();
 }


 Would you guys stand for such a change to be allowed?


If it's an useful feature, then I suggest to integrate  noreturn 
in d/dmd too.

If it's useful but Walter doesn't want it or it can't be 
implemented in dmd, then I suggest to keep using the less common 
pragma(attribute, noreturn) syntax in gdc, to not clash with 
missing but potential D features.

Compiler-specific features should never clash with potential 
future D features.

-------------

Regarding UDAs currently this program gives no warnings:


struct safe {}
 safe void foo() {}
void main() {}


But now foo is not tagged, it's a  safe function. To tag it you 
have to use:

struct safe {}
 (safe) void foo() {}
void main() {}


Is this name clashing acceptable?

(This is also why adding  noreturn to gdc is a bad idea, increase 
even more that confusion.)

Bye,
bearophile
Dec 18 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/18/2012 7:48 AM, bearophile wrote:
  Is this name clashing acceptable?

Yes.
Dec 18 2012
prev sibling parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
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).

To make matters worse, due to the lack of preprocessor in D, 
there's no easy way to work around it (mixins work, but are quite 
ugly).

Finally, if we want to add  noreturn to the spec then it will be 
forced to match the behaviour of the compilers than jumped the 
gun (if you don't then you force those compilers to change their 
implementations to match the spec, breaking their users code that 
already depends on it).

If you do want to add your own attributes then please use names 
like __noreturn, or even __gdc_noreturn so that you don't prevent 
standardised usages being added to the spec.
Dec 18 2012
next sibling parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Tuesday, 18 December 2012 at 16:43:53 UTC, Peter Alexander 
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!


Before anyone says "that would never happen", consider that C++11 
was forced to use 'decltype' instead of the more natual 'typeof' 
because GCC already added 'typeof' as an extension. The same 
thing happened with the containers. GCC added stdext::hash_map as 
an extension, so C++11 had to use the ugly std::unordered_map 
(yep, even the different namespace didn't help).
Dec 18 2012
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 18 December 2012 at 16:47:37 UTC, Peter Alexander 
wrote:

 On Tuesday, 18 December 2012 at 16:43:53 UTC, Peter Alexander 
 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!


 Before anyone says "that would never happen", consider that 
 C++11 was forced to use 'decltype' instead of the more natual 
 'typeof' because GCC already added 'typeof' as an extension. 
 The same thing happened with the containers. GCC added 
 stdext::hash_map as an extension, so C++11 had to use the ugly 
 std::unordered_map (yep, even the different namespace didn't 
 help).


Can you explain why it was an issue in the unordered_map case ? 
Because of using ?

I think this should be advertised that such a feature is in some 
GDC's specific module, and that it can clash with any library 
symbol at any time, as it is not a standardized feature of the 
language.
Dec 18 2012
parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Tuesday, 18 December 2012 at 19:08:06 UTC, deadalnix wrote:

 On Tuesday, 18 December 2012 at 16:47:37 UTC, Peter Alexander 
 wrote:

 On Tuesday, 18 December 2012 at 16:43:53 UTC, Peter Alexander 
 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!


 Before anyone says "that would never happen", consider that 
 C++11 was forced to use 'decltype' instead of the more natual 
 'typeof' because GCC already added 'typeof' as an extension. 
 The same thing happened with the containers. GCC added 
 stdext::hash_map as an extension, so C++11 had to use the ugly 
 std::unordered_map (yep, even the different namespace didn't 
 help).


 Can you explain why it was an issue in the unordered_map case ? 
 Because of using ?


Most probably yes. using namespace std, and using namespace 
stdext are all too common. You can't afford to break that code 
when you update a language as large as C++.


 I think this should be advertised that such a feature is in 
 some GDC's specific module, and that it can clash with any 
 library symbol at any time, as it is not a standardized feature 
 of the language.


Doesn't matter whether you advertise it as experimental or not. 
As we've just seen with Remedy Games and UDAs, as soon as someone 
starts using it in production, whether it's experimental or not, 
you have to support it. That's life.
Dec 18 2012
next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 18 December 2012 at 19:23:18 UTC, Peter Alexander 
wrote:


 I think this should be advertised that such a feature is in 
 some GDC's specific module, and that it can clash with any 
 library symbol at any time, as it is not a standardized 
 feature of the language.


 Doesn't matter whether you advertise it as experimental or not. 
 As we've just seen with Remedy Games and UDAs, as soon as 
 someone starts using it in production, whether it's 
 experimental or not, you have to support it. That's life.


Many other programming languages aren't as conservative as C++. I 
thing the key point here is to have a tool to handle the 
refactoring automatically. It seems way easier to provide such a 
tool in D than in C++.
Dec 18 2012
parent "David Nadlinger" <see klickverbot.at> writes:
On Tuesday, 18 December 2012 at 20:27:31 UTC, deadalnix wrote:

 Many other programming languages aren't as conservative as C++. 
 I thing the key point here is to have a tool to handle the 
 refactoring automatically. It seems way easier to provide such 
 a tool in D than in C++.


I think it's quite the contrary, due to mixin() and the extended 
code generation capabilities of D. In comparison, the C 
preprocessor is pretty limited, at least as far as the typical 
use cases are concerned.

David
Dec 18 2012
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 18 December 2012 19:23, Peter Alexander <peter.alexander.au gmail.com>wrote:


 I think this should be advertised that such a feature is in some GDC's

 specific module, and that it can clash with any library symbol at any time,
 as it is not a standardized feature of the language.


 Doesn't matter whether you advertise it as experimental or not. As we've
 just seen with Remedy Games and UDAs, as soon as someone starts using it in
 production, whether it's experimental or not, you have to support it.
 That's life.



Then again, I am not tied to any particular organisation, so I have no
influence from external bodies during the decision making of when I'm
adding, keeping, or removing any compiler features in the GDC flavour of
D.  I know that probably sounds rather blunt or ignorant, but what I do do
is only ever done on the basis that that was the right thing to do and did
with the best intentions that I had had at the time of doing them.
(Awkward sentence meant for opticron so I can watch him trip and fall over
it :).


An example of a litmus test I've done in the past is something like this:

1) Ask people what would they think if I pull feature X from GDC (eg, D's
.html source support).
2) Listen to the responses, some would agree, but most argue against the
whole idea for legacy reasons.
3) Wait maybe a fortnight whilst I take in all considerations and just do
it anyway.
4) Wait 6-12 months for anyone to notice.
5) No one noticed, thus concluding that:
 a) No one really has any use for it despite what they argue, or
 b) No one infact uses GDC (go figure!).
6) Send a pull request to DMD which gets put through into the next release.


Similarly, no one has noticed that most of the pragma GDC supported have
mysterious vanished either.  The ones left at kept only for gcc.builtins
support until a time I re-implement the attributes in a better way that I
haven't decided on yet (hence why raising this thread).


Regards,
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Dec 18 2012
prev sibling next sibling parent Artur Skawina <art.08.09 gmail.com> writes:
On 12/18/12 21:33, Iain Buclaw wrote:

  b) No one infact uses GDC (go figure!).



 Similarly, no one has noticed that most of the pragma GDC supported have
mysterious vanished either.  The ones left at kept only for gcc.builtins
support until a time I re-implement the attributes in a better way that I
haven't decided on yet (hence why raising this thread).


See above - that's one thing that became completely clear after I first tried
GDC and
filed the ~third gdc bugreport... Right now the situation is even worse, as
dealing
with an experimental language is enough - having to also work with an unstable
compiler is not a practical option. If gdc is upstreamed hopefully some users
will
return and new ones will come.

Pragmas weren't usable, for many obvious reasons, which i have mentioned here
often enough.
Something like  gcc.noreturn will work, /after/ UDAs are properly handled by
the frontend
(aliasing/tuples, attaching to locals (this may already work) and everything
else etc).
The prefix isn't a problem because the typical usage will be

   module config;

   static if (this_is_gcc)
      alias  noreturn =  gcc.noreturn;
   else static if (this_is_whatever)
      alias  noreturn = ID!( whatever.no(return),  whatever.blah);
   else
      alias  noreturn = ID();

Ie no different than C/C++ attribute handling.

artur
Dec 18 2012
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 18 December 2012 21:36, Artur Skawina <art.08.09 gmail.com> wrote:


 On 12/18/12 21:33, Iain Buclaw wrote:

  b) No one infact uses GDC (go figure!).



 Similarly, no one has noticed that most of the pragma GDC supported have


 mysterious vanished either.  The ones left at kept only for gcc.builtins
 support until a time I re-implement the attributes in a better way that I
 haven't decided on yet (hence why raising this thread).

 See above - that's one thing that became completely clear after I first
 tried GDC and
 filed the ~third gdc bugreport... Right now the situation is even worse,
 as dealing
 with an experimental language is enough - having to also work with an
 unstable
 compiler is not a practical option. If gdc is upstreamed hopefully some
 users will
 return and new ones will come.


A lot of these erratic changes stems from code in GDC written during
gcc-3.3 / gcc-3.4 era when GCC frontends typically could include ties to a
particular backend, or when useful parts of the backend could be fleshed
out to the frontend and didn't depend on the frontend language being part
of the C family.

What's left is a fair amount of duplicated code between GDC and GCC (C/C++
front-end's) code base, which core devs don't like.  TARGET macros in GDC,
which core devs especially don't like.  And a balancing act between keeping
the cool features GDC *could* do in the past and what GDC *should* do in
the future to ensure that the frontend should generate code agnostic to any
platform or architecture, pushing out things that can't be done in any
other way into gcc-proper.

Though things have been pretty stable since October... not for long though
as I plan to do another huge face lift in the new year. :-)

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Dec 18 2012
prev sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 18 December 2012 22:23, Iain Buclaw <ibuclaw ubuntu.com> wrote:


 pushing out things that can't be done in any other way into gcc-proper.



One example of this are version identifiers specific to target
architectures.  Where I suggested each target D is ported to should define
it's own TARGET_CPU_D_BUILTINS macro, and each platform it's
TARGET_OS_D_BUILTINS macro.  Both of which are defined outside of gdc.

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Dec 18 2012
prev sibling next sibling parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On 18 December 2012 16:43, Peter Alexander <peter.alexander.au 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.

Others, however yes might have vague meanings....  target,  optimize,
 format...



-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Dec 18 2012
next sibling parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Tuesday, 18 December 2012 at 16:58:32 UTC, Iain Buclaw wrote:

 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.


On *that* particular attribute, I will accept that there isn't 
much you could do differently from a theoretical standardised 
version. The problem is, as soon as you add one compiler specific 
attribute, it will be used as a precedence for adding others.

pragma exists for the purpose of compiler-specific extensions. 
Can we just keep using that, and if an attribute comes up that 
could be truly useful for all compiler then it can be added to 
the spec.
Dec 18 2012
parent reply "jerro" <a a.com> writes:
 On *that* particular attribute, I will accept that there isn't 
 much you could do differently from a theoretical standardised 
 version. The problem is, as soon as you add one compiler 
 specific attribute, it will be used as a precedence for adding 
 others.


You could just name compiler specific attributes something like 
GDC_noreturn, just like http://dlang.org/pragma.html currently 
recommends for pragmas. You could also define them in compiler 
specific modules as has already been discussed in this thread, 
but then code that used them without full names (including the 
module name) would break if an attribute with the same name was 
added to the language.


 pragma exists for the purpose of compiler-specific extensions. 
 Can we just keep using that, and if an attribute comes up that 
 could be truly useful for all compiler then it can be added to 
 the spec.


But you can't do as much with pragmas as you can with attributes. 
For example, you can alias attributes, and I hope you will also 
be able to use tuples of attributes - see my example in this 
thread:

http://forum.dlang.org/thread/uyvdqwslsphshxoioqnw forum.dlang.org
Dec 18 2012
parent reply Johannes Pfau <nospam example.com> writes:
Am Tue, 18 Dec 2012 20:06:16 +0100
schrieb "jerro" <a a.com>:


 You could also define them in compiler 
 specific modules as has already been discussed in this thread, 
 but then code that used them without full names (including the 
 module name) would break if an attribute with the same name was 
 added to the language.


We could do this: Language attributes ( property,  safe, ...) are
defined in "lang.attributes" (or choose some other name). Then add a
public import of lang.attributes to object.di. 

GDC attributes are defined in gdc.attributes (or any other name). We
could add an public import to object.di for gdc. Or we don't, that's a
different discussion.

The result is that you can always resolve conflicting attributes:
If gdc introduces  noreturn in gdc.attributes you can now do this:
------------------------
//(Optional if gdc.attributes is imported in
//object.di)
import gdc.attributes;

 noreturn void foo{}
------------------------

If a  noreturn attribute is now added to lang.attributes, the compiler
will refuse to compile the above code as it's ambiguous. But you can
now do this:

 lang.attributes.noreturn void foo{}
or
 gdc.attributes.noreturn void foo{}

or
import gdc = gdc.attributes;
 gdc.noreturn void foo{}
Dec 18 2012
next sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On 2012-11-18 21:12, Johannes Pfau <nospam example.com> wrote:


 Am Tue, 18 Dec 2012 20:06:16 +0100
 schrieb "jerro" <a a.com>:


 You could also define them in compiler
 specific modules as has already been discussed in this thread,
 but then code that used them without full names (including the
 module name) would break if an attribute with the same name was
 added to the language.


 We could do this: Language attributes ( property,  safe, ...) are
 defined in "lang.attributes" (or choose some other name). Then add a
 public import of lang.attributes to object.di.

 GDC attributes are defined in gdc.attributes (or any other name). We
 could add an public import to object.di for gdc. Or we don't, that's a
 different discussion.

 The result is that you can always resolve conflicting attributes:
 If gdc introduces  noreturn in gdc.attributes you can now do this:
 ------------------------
 //(Optional if gdc.attributes is imported in
 //object.di)
 import gdc.attributes;

  noreturn void foo{}
 ------------------------

 If a  noreturn attribute is now added to lang.attributes, the compiler
 will refuse to compile the above code as it's ambiguous. But you can
 now do this:

  lang.attributes.noreturn void foo{}
 or
  gdc.attributes.noreturn void foo{}

 or
 import gdc = gdc.attributes;
  gdc.noreturn void foo{}


This certainly sounds like the sanest solution.

-- 
Simen
Dec 18 2012
prev sibling parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On 18 December 2012 20:11, Johannes Pfau <nospam example.com> wrote:


 Am Tue, 18 Dec 2012 20:06:16 +0100
 schrieb "jerro" <a a.com>:


 You could also define them in compiler
 specific modules as has already been discussed in this thread,
 but then code that used them without full names (including the
 module name) would break if an attribute with the same name was
 added to the language.


 We could do this: Language attributes ( property,  safe, ...) are
 defined in "lang.attributes" (or choose some other name). Then add a
 public import of lang.attributes to object.di.

 GDC attributes are defined in gdc.attributes (or any other name). We
 could add an public import to object.di for gdc. Or we don't, that's a
 different discussion.

 The result is that you can always resolve conflicting attributes:
 If gdc introduces  noreturn in gdc.attributes you can now do this:
 ------------------------
 //(Optional if gdc.attributes is imported in
 //object.di)
 import gdc.attributes;

  noreturn void foo{}
 ------------------------

 If a  noreturn attribute is now added to lang.attributes, the compiler
 will refuse to compile the above code as it's ambiguous. But you can
 now do this:

  lang.attributes.noreturn void foo{}
 or
  gdc.attributes.noreturn void foo{}

 or
 import gdc = gdc.attributes;
  gdc.noreturn void foo{}



Someone recently mentioned  gccAttribute("foo", "bar");  as a prototype.


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Dec 28 2012
parent Johannes Pfau <nospam example.com> writes:
Am Fri, 28 Dec 2012 13:28:51 +0000
schrieb Iain Buclaw <ibuclaw ubuntu.com>:

 
 
 Someone recently mentioned  gccAttribute("foo", "bar");  as a
 prototype.
 
 


That looks like a good solution. And it should be much simpler to
implement than my proposal.
Dec 28 2012
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/18/12 11:58 AM, Iain Buclaw wrote:

 On 18 December 2012 16:43, Peter Alexander <peter.alexander.au gmail.com
 <mailto:peter.alexander.au 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
Dec 18 2012
parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 18 December 2012 21:31, Andrei Alexandrescu <
SeeWebsiteForEmail erdani.org> wrote:


 On 12/18/12 11:58 AM, Iain Buclaw wrote:


 On 18 December 2012 16:43, Peter Alexander <peter.alexander.au gmail.com
 <mailto:peter.alexander.au **gmail.com <peter.alexander.au 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';
Dec 18 2012
prev sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 18 December 2012 16:58, Iain Buclaw <ibuclaw ubuntu.com> wrote:


 On 18 December 2012 16:43, Peter Alexander <peter.alexander.au 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.


Might believe you. :=)

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Dec 18 2012