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.

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';

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';

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.

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';

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

On 12/18/2012 7:48 AM, bearophile wrote:
 Is this name clashing acceptable?

Yes.

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.

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

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';