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:
--20cf307f341263999704d1221854
Content-Type: text/plain; charset=ISO-8859-1

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

 Potentially this can now be re-written as.

 void die()  noreturn
 {
    abort();
 }

http://forum.dlang.org/thread/i9p9li$282u$1 digitalmars.com -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0'; --20cf307f341263999704d1221854 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_extra"><div class=3D"gmail_quote">On 18 December 2012 1= 5:19, Iain Buclaw <span dir=3D"ltr">&lt;<a href=3D"mailto:ibuclaw ubuntu.co= m" target=3D"_blank">ibuclaw ubuntu.com</a>&gt;</span> wrote:<br><blockquot= e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s= olid rgb(204,204,204);padding-left:1ex"> Potentially this can now be re-written as.<br> <br> void die() noreturn<br> {<br> =A0 =A0abort();<br> }<br> <br clear=3D"all"></blockquote></div><br>By the way, this would be the firs= t time that noreturn has been brought up.<br><br><a href=3D"http://forum.d= lang.org/thread/i9p9li$282u$1 digitalmars.com">http://forum.dlang.org/threa= d/i9p9li$282u$1 digitalmars.com</a><br> <br><br>-- <br>Iain Buclaw<br><br>*(p &lt; e ? p++ : p) =3D (c &amp; 0x0f) = + &#39;0&#39;;<br> </div> --20cf307f341263999704d1221854--
Dec 18 2012
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
--047d7bdc7a9acfc14d04d122244e
Content-Type: text/plain; charset=ISO-8859-1

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();
 }

up.

s/would/wouldn't/ -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0'; --047d7bdc7a9acfc14d04d122244e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_extra"><div class=3D"gmail_quote">On 18 December 2012 1= 5:24, Iain Buclaw <span dir=3D"ltr">&lt;<a href=3D"mailto:ibuclaw ubuntu.co= m" target=3D"_blank">ibuclaw ubuntu.com</a>&gt;</span> wrote:<br><blockquot= e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol= id;padding-left:1ex"> <div class=3D"gmail_extra"><div class=3D"im"><div class=3D"gmail_quote">On = 18 December 2012 15:19, Iain Buclaw <span dir=3D"ltr">&lt;<a href=3D"mailto= :ibuclaw ubuntu.com" target=3D"_blank">ibuclaw ubuntu.com</a>&gt;</span> wr= ote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left:1px solid rgb(204,204,204);padding-left:1ex"> Potentially this can now be re-written as.<br> <br> void die() noreturn<br> {<br> =A0 =A0abort();<br> }<br> <br clear=3D"all"></blockquote></div><br></div>By the way, this would be th= e first time that noreturn has been brought up.<br clear=3D"all"></div></b= lockquote></div><br>s/would/wouldn&#39;t/<br><br>-- <br>Iain Buclaw<br><br> *(p &lt; e ? p++ : p) =3D (c &amp; 0x0f) + &#39;0&#39;;<br> </div> --047d7bdc7a9acfc14d04d122244e--
Dec 18 2012
prev sibling next sibling parent "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
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
--047d7bdc7a9a01295604d122641c
Content-Type: text/plain; charset=ISO-8859-1

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'; --047d7bdc7a9a01295604d122641c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_extra"><div class=3D"gmail_quote">On 18 December 2012 1= 5:29, Adam D. Ruppe <span dir=3D"ltr">&lt;<a href=3D"mailto:destructionator= gmail.com" target=3D"_blank">destructionator gmail.com</a>&gt;</span> wrot= e:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b= order-left:1px solid rgb(204,204,204);padding-left:1ex"> <div class=3D"im">On Tuesday, 18 December 2012 at 15:19:58 UTC, Iain Buclaw= wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left:1px solid rgb(204,204,204);padding-left:1ex"> Should we take this as an opportunity for other compiler maintainers to imp= lement their own compiler-specific predefined attributes?<br> </blockquote> <br></div> I think it&#39;d be great if we used magical full names, but otherwise it i= s the same as the library. Then they are namespaced and can be shared.<br> <br> module core.gdc;<br> struct noreturn {}<br> // and whatever<br> <br> <br> Then when you use it, you import core.gdc and use noreturn. The compiler d= oesn&#39;t define the attribute, but it recognizes the full name of core.gd= c.noreturn and gives it special treatment like an intrinsic.<br> </blockquote></div><br>If doing it that way, it would be better to store al= l predefined attributes into a binary tree.<br><br>UserAttributeDeclaration= ::addPredefinedAttribute(&quot;property&quot;);=A0 // etc<br><br><br>And ha= ve a magical empty module, gcc.attributes, which when imported injects the = compiler-specific attributes.<br> <br>UserAttributeDeclaration::addPredefinedAttribute(&quot;noreturn&quot;);= =A0 // etc<br><br><br>-- <br>Iain Buclaw<br><br>*(p &lt; e ? p++ : p) =3D (= c &amp; 0x0f) + &#39;0&#39;;<br> </div> --047d7bdc7a9a01295604d122641c--
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 next 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 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
prev 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 "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
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
--f46d04389121e4989c04d12367e3
Content-Type: text/plain; charset=ISO-8859-1

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

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'; --f46d04389121e4989c04d12367e3 Content-Type: text/html; charset=ISO-8859-1 <div class="gmail_extra"><div class="gmail_quote">On 18 December 2012 16:43, Peter Alexander <span dir="ltr">&lt;<a href="mailto:peter.alexander.au gmail.com" target="_blank">peter.alexander.au gmail.com</a>&gt;</span> wrote:<br> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">On Tuesday, 18 December 2012 at 15:19:58 UTC, Iain Buclaw wrote:<br> </div><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Should we take this as an opportunity for other compiler maintainers to implement their own compiler-specific predefined attributes?<br> </blockquote> <br></div> Please, no!<br> <br> Suppose GDC implements noreturn (or whatever other attribute)<br> <br> Later, LDC implements noreturn separately with slightly different semantics.<br> <br> 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).<br> <br clear="all"></blockquote></div><br>Provide a situation where noreturn attribute would mean anything other than telling the compiler to assume that the function<code></code> cannot return, and I might please you on *that* particular attribute.<br> <br>Others, however yes might have vague meanings.... target, optimize, format...<br><br><br><br>-- <br>Iain Buclaw<br><br>*(p &lt; e ? p++ : p) = (c &amp; 0x0f) + &#39;0&#39;;<br> </div> --f46d04389121e4989c04d12367e3--
Dec 18 2012
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
--20cf307f397c7b298404d1236a72
Content-Type: text/plain; charset=ISO-8859-1

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

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'; --20cf307f397c7b298404d1236a72 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_extra"><div class=3D"gmail_quote">On 18 December 2012 1= 6:58, Iain Buclaw <span dir=3D"ltr">&lt;<a href=3D"mailto:ibuclaw ubuntu.co= m" target=3D"_blank">ibuclaw ubuntu.com</a>&gt;</span> wrote:<br><blockquot= e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol= id;padding-left:1ex"> <div class=3D"gmail_extra"><div class=3D"im"><div class=3D"gmail_quote">On = 18 December 2012 16:43, Peter Alexander <span dir=3D"ltr">&lt;<a href=3D"ma= ilto:peter.alexander.au gmail.com" target=3D"_blank">peter.alexander.au gma= il.com</a>&gt;</span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left:1px solid rgb(204,204,204);padding-left:1ex"><div>On Tuesday, 18 Decem= ber 2012 at 15:19:58 UTC, Iain Buclaw wrote:<br> </div><div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.= 8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Should we take this as an opportunity for other compiler maintainers to imp= lement their own compiler-specific predefined attributes?<br> </blockquote> <br></div> Please, no!<br> <br> Suppose GDC implements noreturn (or whatever other attribute)<br> <br> Later, LDC implements noreturn separately with slightly different semantic= s.<br> <br> We now end up in a situation where noreturn cannot be used portably, and n= either compiler developer has incentive to change (whoever changes breaks t= heir users code).<br> <br clear=3D"all"></blockquote></div><br></div>Provide a situation where n= oreturn attribute would mean anything other than telling the compiler to as= sume that the function<code></code> cannot return, and I might please you o= n *that* particular attribute.<br clear=3D"all"> </div></blockquote></div><br>Might believe you. :=3D)<br><br>-- <br>Iain Bu= claw<br><br>*(p &lt; e ? p++ : p) =3D (c &amp; 0x0f) + &#39;0&#39;;<br> </div> --20cf307f397c7b298404d1236a72--
Dec 18 2012
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent 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
prev sibling next sibling parent "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
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
--20cf307f3a56863bf504d12667ac
Content-Type: text/plain; charset=ISO-8859-1

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'; --20cf307f3a56863bf504d12667ac Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_extra"><div class=3D"gmail_quote">On 18 December 2012 1= 9:23, Peter Alexander <span dir=3D"ltr">&lt;<a href=3D"mailto:peter.alexand= er.au gmail.com" target=3D"_blank">peter.alexander.au gmail.com</a>&gt;</sp= an> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left:1px solid rgb(204,204,204);padding-left:1ex"><div class=3D"im"><blockq= uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p= x solid rgb(204,204,204);padding-left:1ex"> I think this should be advertised that such a feature is in some GDC&#39;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.<br> </blockquote> <br></div> Doesn&#39;t matter whether you advertise it as experimental or not. As we&#= 39;ve just seen with Remedy Games and UDAs, as soon as someone starts using= it in production, whether it&#39;s experimental or not, you have to suppor= t it. That&#39;s life.</blockquote> </div><br>Then again, I am not tied to any particular organisation, so I ha= ve no influence from external bodies during the decision making of when I&#= 39;m adding, keeping, or removing any compiler features in the GDC=20 flavour of D.=A0 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 t= o do and did with the best intentions that I had had at the time of doing t= hem.=A0 (Awkward sentence meant for opticron so I can watch him trip and fa= ll over it :).<br> <br><br>An example of a litmus test I&#39;ve done in the past is something = like this:<br><br>1) Ask people what would they think if I pull feature X f= rom GDC (eg, D&#39;s .html source support).<br>2) Listen to the responses, = some would agree, but most argue against the whole idea for legacy reasons.= <br> 3) Wait maybe a fortnight whilst I take in all considerations and just do i= t anyway.<br>4) Wait 6-12 months for anyone to notice.<br>5) No one noticed= , thus concluding that:<br>=A0a) No one really has any use for it despite w= hat they argue, or<br> =A0b) No one infact uses GDC (go figure!).<br>6) Send a pull request to DMD= which gets put through into the next release.<br><br clear=3D"all"><br>Sim= ilarly, no one has noticed that most of the pragma GDC supported have myste= rious vanished either.=A0 The ones left at kept only for gcc.builtins suppo= rt until a time I re-implement the attributes in a better way that I haven&= #39;t decided on yet (hence why raising this thread).<br> <br><br>Regards,<br>-- <br>Iain Buclaw<br><br>*(p &lt; e ? p++ : p) =3D (c = &amp; 0x0f) + &#39;0&#39;;<br> </div> --20cf307f3a56863bf504d12667ac--
Dec 18 2012
prev sibling next sibling 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:
--047d7bf0effe98466904d127aea1
Content-Type: text/plain; charset=ISO-8859-1

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'; --047d7bf0effe98466904d127aea1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_extra"><div class=3D"gmail_quote">On 18 December 2012 2= 1:31, Andrei Alexandrescu <span dir=3D"ltr">&lt;<a href=3D"mailto:SeeWebsit= eForEmail erdani.org" target=3D"_blank">SeeWebsiteForEmail erdani.org</a>&g= t;</span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div class=3D"im">On 12/18/12 11:58 AM, Iain= Buclaw wrote:<br> </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex"><div class=3D"im"> On 18 December 2012 16:43, Peter Alexander &lt;<a href=3D"mailto:peter.alex= ander.au gmail.com" target=3D"_blank">peter.alexander.au gmail.com</a><br><= /div><div class=3D"im"> &lt;mailto:<a href=3D"mailto:peter.alexander.au gmail.com" target=3D"_blank= ">peter.alexander.au <u></u>gmail.com</a>&gt;&gt; wrote:<br> <br> =A0 =A0 On Tuesday, 18 December 2012 at 15:19:58 UTC, Iain Buclaw wrote:<br=

=A0 =A0 =A0 =A0 Should we take this as an opportunity for other compiler<br=

ined<br> =A0 =A0 =A0 =A0 attributes?<br> <br> <br> =A0 =A0 Please, no!<br> <br> =A0 =A0 Suppose GDC implements noreturn (or whatever other attribute)<br> <br> =A0 =A0 Later, LDC implements noreturn separately with slightly different<= br> =A0 =A0 semantics.<br> <br> =A0 =A0 We now end up in a situation where noreturn cannot be used<br> =A0 =A0 portably, and neither compiler developer has incentive to change<br=

<br> <br></div><div class=3D"im"> Provide a situation where noreturn attribute would mean anything other<br> than telling the compiler to assume that the function|| cannot return,<br> and I might please you on *that* particular attribute.<br> </div></blockquote> <br> One possibility: one compiler assumes noreturn never returns, whereas anot= her enforces that by adding an HLT at the end of the function.<span class= =3D"HOEnZb"><font color=3D"#888888"><br> <br> Andrei<br> <br> </font></span></blockquote></div><br><br>The effect would really be the sam= e though.=A0 Typically in a noreturn function, there is no &#39;ret&#39;, = so if the function were to return, the stack would be left corrupt.=A0 The = key difference is that whilst in one program, it halts at the point of the = program that should never be reached.=A0 The other crashes an burns with a = HLT or SEGV shortly afterwards.<br> <br>This behaviour I describe incidentally is the case with assert(0) in re= lease code right now.=A0 Different compilers handle it differently, DMD jus= t so happens to enforce that by adding a HTL at the end whilst others don&#= 39;t.<br clear=3D"all"> <br>-- <br>Iain Buclaw<br><br>*(p &lt; e ? p++ : p) =3D (c &amp; 0x0f) + &#= 39;0&#39;;<br> </div> --047d7bf0effe98466904d127aea1--
Dec 18 2012
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
--047d7bf0effe48f5d204d127f449
Content-Type: text/plain; charset=ISO-8859-1

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

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.

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'; --047d7bf0effe48f5d204d127f449 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_extra"><div class=3D"gmail_quote">On 18 December 2012 2= 1:36, Artur Skawina <span dir=3D"ltr">&lt;<a href=3D"mailto:art.08.09 gmail= .com" target=3D"_blank">art.08.09 gmail.com</a>&gt;</span> wrote:<br><block= quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc= solid;padding-left:1ex"> <div class=3D"im">On 12/18/12 21:33, Iain Buclaw wrote:<br> &gt; =A0b) No one infact uses GDC (go figure!).<br> <br> </div><div class=3D"im">&gt; Similarly, no one has noticed that most of the= pragma GDC supported have mysterious vanished either. =A0The ones left at = kept only for gcc.builtins support until a time I re-implement the attribut= es in a better way that I haven&#39;t decided on yet (hence why raising thi= s thread).<br> <br> </div>See above - that&#39;s one thing that became completely clear after I= first tried GDC and<br> filed the ~third gdc bugreport... Right now the situation is even worse, as= dealing<br> with an experimental language is enough - having to also work with an unsta= ble<br> compiler is not a practical option. If gdc is upstreamed hopefully some use= rs will<br> return and new ones will come.<br> <br></blockquote></div><br>A lot of these erratic changes stems from code i= n GDC written during gcc-3.3 / gcc-3.4 era when GCC frontends typically cou= ld include ties to a particular backend, or when useful parts of the backen= d could be fleshed out to the frontend and didn&#39;t depend on the fronten= d language being part of the C family.<br clear=3D"all"> <br>What&#39;s left is a fair amount of duplicated code between GDC and GCC= (C/C++ front-end&#39;s) code base, which core devs don&#39;t like.=A0 TARG= ET macros in GDC, which core devs especially don&#39;t like.=A0 And a balan= cing act between keeping the cool features GDC *could* do in the past and w= hat GDC *should* do in the future to ensure that the frontend should genera= te code agnostic to any platform or architecture, pushing out things that c= an&#39;t be done in any other way into gcc-proper.<br> <br>Though things have been pretty stable since October... not for long tho= ugh as I plan to do another huge face lift in the new year. :-)<br><br>-- <= br>Iain Buclaw<br><br>*(p &lt; e ? p++ : p) =3D (c &amp; 0x0f) + &#39;0&#39= ;;<br> </div> --047d7bf0effe48f5d204d127f449--
Dec 18 2012
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
--f46d0438936f05594904d12801cc
Content-Type: text/plain; charset=ISO-8859-1

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'; --f46d0438936f05594904d12801cc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_extra"><div class=3D"gmail_quote">On 18 December 2012 2= 2:23, Iain Buclaw <span dir=3D"ltr">&lt;<a href=3D"mailto:ibuclaw ubuntu.co= m" target=3D"_blank">ibuclaw ubuntu.com</a>&gt;</span> wrote:<br><blockquot= e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol= id;padding-left:1ex"> pushing out things that can&#39;t be done in any other way into gcc-proper.= </blockquote></div><br>One example of this are version identifiers specific= to target architectures.=A0 Where I suggested each target D is ported to s= hould define it&#39;s own TARGET_CPU_D_BUILTINS macro, and each platform it= &#39;s TARGET_OS_D_BUILTINS macro.=A0 Both of which are defined outside of = gdc.<br clear=3D"all"> <br>-- <br>Iain Buclaw<br><br>*(p &lt; e ? p++ : p) =3D (c &amp; 0x0f) + &#= 39;0&#39;;<br> </div> --f46d0438936f05594904d12801cc--
Dec 18 2012
prev sibling 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 next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
--20cf307f397cf54b8a04d1e9a447
Content-Type: text/plain; charset=ISO-8859-1

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'; --20cf307f397cf54b8a04d1e9a447 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 1= 8 December 2012 20:11, Johannes Pfau <span dir=3D"ltr">&lt;<a href=3D"mailt= o:nospam example.com" target=3D"_blank">nospam example.com</a>&gt;</span> w= rote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">Am Tue, 18 Dec 2012 20:06:16 +0100<br> schrieb &quot;jerro&quot; &lt;<a href=3D"mailto:a a.com">a a.com</a>&gt;:<b= r> <div class=3D"im"><br> &gt; You could also define them in compiler<br> &gt; specific modules as has already been discussed in this thread,<br> &gt; but then code that used them without full names (including the<br> &gt; module name) would break if an attribute with the same name was<br> &gt; added to the language.<br> <br> </div>We could do this: Language attributes ( property, safe, ...) are<br> defined in &quot;lang.attributes&quot; (or choose some other name). Then ad= d a<br> public import of lang.attributes to object.di.<br> <br> GDC attributes are defined in gdc.attributes (or any other name). We<br> could add an public import to object.di for gdc. Or we don&#39;t, that&#39;= s a<br> different discussion.<br> <br> The result is that you can always resolve conflicting attributes:<br> If gdc introduces noreturn in gdc.attributes you can now do this:<br> ------------------------<br> //(Optional if gdc.attributes is imported in<br> //object.di)<br> import gdc.attributes;<br> <br> noreturn void foo{}<br> ------------------------<br> <br> If a noreturn attribute is now added to lang.attributes, the compiler<br> will refuse to compile the above code as it&#39;s ambiguous. But you can<br=

<br> lang.attributes.noreturn void foo{}<br> or<br> gdc.attributes.noreturn void foo{}<br> <br> or<br> import gdc =3D gdc.attributes;<br> gdc.noreturn void foo{}<br> </blockquote></div><br><br></div><div class=3D"gmail_extra">Someone recentl= y mentioned gccAttribute(&quot;foo&quot;, &quot;bar&quot;);=A0 as a protot= ype.<br><br clear=3D"all"></div><div class=3D"gmail_extra"><br>-- <br>Iain = Buclaw<br> <br>*(p &lt; e ? p++ : p) =3D (c &amp; 0x0f) + &#39;0&#39;; </div></div> --20cf307f397cf54b8a04d1e9a447--
Dec 28 2012
prev sibling 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