On 11/7/2012 11:27 PM, Jacob Carlborg wrote:
> On 2012-11-08 02:49, Walter Bright wrote:
>
>> Yes, that makes the attribute global.
>
> I don't actually know how this works in Java but if you are forced to use the
> fully qualified name for the attribute it won't make the attribute global.
>

A plugin would apply globally, wouldn't it?

On 2012-11-08 11:56, Walter Bright wrote:

> A plugin would apply globally, wouldn't it?

Yes, but that wouldn't make the attribute global. I just had a quick look on the Annotation Processing Tool (APT) available in Java. This tool will run an annotation processor over some specified Java files. It will then generate a new set of files with the result of the annotation process. In the annotation processor you have to specify what annotations you want to process. You can either specify you want to process all annotations, "*", or a single annotation, "foo.bar.Baz".

http://docs.oracle.com/javase/1.5.0/docs/guide/apt/GettingStarted.html

-- 
/Jacob Carlborg

On 2012-11-08 10:08, Max Samukha wrote:

> Could you explain why it is impossible without complicating the current
> state of things? I gave it a quick try and it seems to work reasonably
> well (a proper implementation will be more involved due to compiler bugs
> and language issues irrelevant to this discussion):

I just see no point in allowing random structs and classes acting like attributes.

Suddenly someone starts to use your struct as an attribute without you having any intention of it acting like an attribute and you don't know about it.

-- 
/Jacob Carlborg

On Thursday, 8 November 2012 at 12:42:38 UTC, Jacob Carlborg wrote:
> On 2012-11-08 10:08, Max Samukha wrote:
>
>> Could you explain why it is impossible without complicating the current
>> state of things? I gave it a quick try and it seems to work reasonably
>> well (a proper implementation will be more involved due to compiler bugs
>> and language issues irrelevant to this discussion):
>
> I just see no point in allowing random structs and classes acting like attributes.
>
> Suddenly someone starts to use your struct as an attribute without you having any intention of it acting like an attribute and you don't know about it.

The problem is where to draw the line. There is nothing to stop an idiot programmer from applying your attributes to a wrong target, so we'd better take care of that by introducing those target-restricting attributes specially treated by the compiler.

Instead of throwing attributes on attributes, I'd rather have decorators based on templates as someone proposed. Those would allow the programmer to implement arbitrary restrictions on their usage.

On 11/8/2012 4:37 AM, Jacob Carlborg wrote:
> On 2012-11-08 11:56, Walter Bright wrote:
>
>> A plugin would apply globally, wouldn't it?
>
> Yes, but that wouldn't make the attribute global. I just had a quick look on the
> Annotation Processing Tool (APT) available in Java. This tool will run an
> annotation processor over some specified Java files. It will then generate a new
> set of files with the result of the annotation process. In the annotation
> processor you have to specify what annotations you want to process. You can
> either specify you want to process all annotations, "*", or a single annotation,
> "foo.bar.Baz".
>
> http://docs.oracle.com/javase/1.5.0/docs/guide/apt/GettingStarted.html
>

I believe that does have the essential effect of making the attribute global.

On 2012-11-08 20:39, Walter Bright wrote:

> I believe that does have the essential effect of making the attribute
> global.

I don't understand how.

-- 
/Jacob Carlborg

On Wednesday, 7 November 2012 at 08:41:48 UTC, Walter Bright wrote:
> New version up now with a couple reported problems with UDA fixed.

I may have found a little glitch...?

mixin("[1] int a;");
["[2] int b;"] int c;
mixin(__traits(getAttributes, c)[0]);

pragma(msg, __traits(getAttributes, a)); => tuple()
pragma(msg, __traits(getAttributes, b)); => tuple()


The use-case for this is parsing a foreign language which will be compiled to  mixed in d-code.

On 11/8/2012 12:00 PM, Jacob Carlborg wrote:
> On 2012-11-08 20:39, Walter Bright wrote:
>
>> I believe that does have the essential effect of making the attribute
>> global.
>
> I don't understand how.
>

Because plugins are a global thing. If you have a plugin that deals with attribute 'X', then you cannot have two plugins that interpret 'X' differently, i.e. 'X' becomes, for all practical purposes, global.

On 2012-11-08 23:31, Walter Bright wrote:

> Because plugins are a global thing. If you have a plugin that deals with
> attribute 'X', then you cannot have two plugins that interpret 'X'
> differently, i.e. 'X' becomes, for all practical purposes, global.

Well, 'X' is supposed to be the fully qualified name. Can I have my own symbol named std.algorithm.filter and use it together with the std.algorithm.filter function in Phobos?

-- 
/Jacob Carlborg

On 2012-11-08 19:03, Max Samukha wrote:

> The problem is where to draw the line. There is nothing to stop an idiot
> programmer from applying your attributes to a wrong target, so we'd
> better take care of that by introducing those target-restricting
> attributes specially treated by the compiler.

Sure, but we don't want to have a comment for every struct indented as an attribute saying "this is an attribute". We do have "const", "pure", "nothrow" and so on for a reason. We want the compiler to be able to force/validate our intent and not have to write the intention in the documentation.

-- 
/Jacob Carlborg