I just want to add more real-world experience to the controversy. I'm finding myself needing to use custom attributes almost every day.

I have numerous systems that need to scan the module for things marked accordingly to automate bindings to their respective systems.

This is my current list of attributes I want to mark things with:
  Export to game engine
  Export to script language
  Import from game engine
  ** Import from script language (tentative, I'm sure I'll need it in a few
more days)
  Expose to editor (with additional properties; description, edit type, etc)
  Serialise (load/save game)
  Replay serialisation (a different kind of serialisation that works with
different data sets)

And others I've encountered in passing that I can't recall right now.

As you can imagine, any attempt to 'work around' the lack of an attribute
system, ie, (ab)using enums, etc as have been suggested, leads to a big
mess in the context of all these requirements.
Management of such lists of stuff in disconnected places in code is time
consuming, thoroughly annoying, error-prone, difficult to maintain, and
leaves programmers with the bitter taste of C++.
Alternatively, wrapping virtually every single declaration made in mixin()
and declaring everything as strings is even more nasty, and the contrast
between mixin() declarations and 'normal' declarations looks completely
stupid. (Totally unreadable + difficult to understand, breaks intellisense,
code completion, syntax hilighting, etc... ie, unusable)

Does anyone have a *realistic* suggestion for emulating custom attributes?
Something that doesn't have any(/many) of the side effects I mention?
I haven't come up with anything that's acceptable yet.

If not, I assert that D absolutely needs a custom attribute system. For us
here, this will enable D the single biggest advantage over using C++ in the
same context that I've identified so far.
D's meta-programming is amazing, but sadly, proving pointless to me right
now without being able to mark stuff appropriately. All the meta magic is
hovering just out of my grasp, due to the fact I have no way to indicate
what items should involve with what systems.
Currently, I have to maintain big registry tables of junk that must be
amended/updated any time anyone adds/changes anything... and I'm feeling
rather embarrassed when I tell the other non-D programmers that they just
need to update this table here... and here... and make sure that's in sync
too before their stuff will just 'magically' work ;)

C# and Java both have attributes, following these established design patterns, I don't think there should be any mystery over how they should be implemented.

Manu,

as a workaround would marker interfaces help to solve your problem for the time being?

This is just a suggestion for the time being, as I agree with you, attributes/annotations are quite handy.

--
Paulo

"Manu" <turkeyman@gmail.com> wrote in message news:mailman.1363.1333627256.4860.digitalmars-d@puremagic.com...
I just want to add more real-world experience to the controversy.
I'm finding myself needing to use custom attributes almost every day.

I have numerous systems that need to scan the module for things marked accordingly to automate bindings to their respective systems.

This is my current list of attributes I want to mark things with:
  Export to game engine
  Export to script language
  Import from game engine
  ** Import from script language (tentative, I'm sure I'll need it in a few more days)
  Expose to editor (with additional properties; description, edit type, etc)
  Serialise (load/save game)
  Replay serialisation (a different kind of serialisation that works with different data sets)

And others I've encountered in passing that I can't recall right now.

As you can imagine, any attempt to 'work around' the lack of an attribute system, ie, (ab)using enums, etc as have been suggested, leads to a big mess in the context of all these requirements.
Management of such lists of stuff in disconnected places in code is time consuming, thoroughly annoying, error-prone, difficult to maintain, and leaves programmers with the bitter taste of C++.
Alternatively, wrapping virtually every single declaration made in mixin() and declaring everything as strings is even more nasty, and the contrast between mixin() declarations and 'normal' declarations looks completely stupid. (Totally unreadable + difficult to understand, breaks intellisense, code completion, syntax hilighting, etc... ie, unusable)

Does anyone have a *realistic* suggestion for emulating custom attributes? Something that doesn't have any(/many) of the side effects I mention?
I haven't come up with anything that's acceptable yet.

If not, I assert that D absolutely needs a custom attribute system. For us here, this will enable D the single biggest advantage over using C++ in the same context that I've identified so far.
D's meta-programming is amazing, but sadly, proving pointless to me right now without being able to mark stuff appropriately. All the meta magic is hovering just out of my grasp, due to the fact I have no way to indicate what items should involve with what systems.
Currently, I have to maintain big registry tables of junk that must be amended/updated any time anyone adds/changes anything... and I'm feeling rather embarrassed when I tell the other non-D programmers that they just need to update this table here... and here... and make sure that's in sync too before their stuff will just 'magically' work ;)

C# and Java both have attributes, following these established design patterns, I don't think there should be any mystery over how they should be implemented.

On 5 April 2012 15:04, Paulo Pinto <pjmlp@progtools.org> wrote:

>   as a workaround would marker interfaces help to solve your problem for
> the time being?
>

I don't think it'd suit my purposes implemented as an interface for a
variety of reasons:
  I need to be able to attribute many different types of things; data
members, static functions, methods, etc.
  I need to be able to annotate 'loose' things at module scope.
  The whole point of the system is that it doesn't enforce a rigid
interface. From my examples above, these items could be basically anything,
anywhere.

Paulo Pinto:

> C# and Java both have attributes, following these established design patterns, I don't think there should be any mystery over how they should be implemented.

There are other interesting ways to conceive attributes. I think of them in a different way, more like user-defined ways to extend the static type system.

Bye,
bearophile

On 4/5/2012 5:00 AM, Manu wrote:
> C# and Java both have attributes, following these established design patterns, I
> don't think there should be any mystery over how they should be implemented.

At the Lang.NEXT conference over the last 3 days, I was able to talk to many smart people about attributes. But I did find some confusion - are they best attached to the variable/function (i.e. "storage class"), or attached to the type ("type constructor")? I think the former. Attaching it to the type leads to all sorts of semantic issues.

From your list of uses, it looks like attaching it to the variable or function is an apropos solution.

Le 05/04/2012 19:35, Walter Bright a écrit :
> On 4/5/2012 5:00 AM, Manu wrote:
>> C# and Java both have attributes, following these established design
>> patterns, I
>> don't think there should be any mystery over how they should be
>> implemented.
>
> At the Lang.NEXT conference over the last 3 days, I was able to talk to
> many smart people about attributes. But I did find some confusion - are
> they best attached to the variable/function (i.e. "storage class"), or
> attached to the type ("type constructor")? I think the former. Attaching
> it to the type leads to all sorts of semantic issues.
>
>  From your list of uses, it looks like attaching it to the variable or
> function is an apropos solution.

They should be attached to declarations.

On 4/5/12 12:44 PM, deadalnix wrote:
> Le 05/04/2012 19:35, Walter Bright a écrit :
>> On 4/5/2012 5:00 AM, Manu wrote:
>>> C# and Java both have attributes, following these established design
>>> patterns, I
>>> don't think there should be any mystery over how they should be
>>> implemented.
>>
>> At the Lang.NEXT conference over the last 3 days, I was able to talk to
>> many smart people about attributes. But I did find some confusion - are
>> they best attached to the variable/function (i.e. "storage class"), or
>> attached to the type ("type constructor")? I think the former. Attaching
>> it to the type leads to all sorts of semantic issues.
>>
>> From your list of uses, it looks like attaching it to the variable or
>> function is an apropos solution.
>
> They should be attached to declarations.

The question was whether the declaration affects the type of the declared or not.

Andrei

On Thu, 05 Apr 2012 14:05:49 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 4/5/12 12:44 PM, deadalnix wrote:
>> Le 05/04/2012 19:35, Walter Bright a écrit :
>>> On 4/5/2012 5:00 AM, Manu wrote:
>>>> C# and Java both have attributes, following these established design
>>>> patterns, I
>>>> don't think there should be any mystery over how they should be
>>>> implemented.
>>>
>>> At the Lang.NEXT conference over the last 3 days, I was able to talk to
>>> many smart people about attributes. But I did find some confusion - are
>>> they best attached to the variable/function (i.e. "storage class"), or
>>> attached to the type ("type constructor")? I think the former. Attaching
>>> it to the type leads to all sorts of semantic issues.
>>>
>>> From your list of uses, it looks like attaching it to the variable or
>>> function is an apropos solution.
>>
>> They should be attached to declarations.
>
> The question was whether the declaration affects the type of the declared or not.

For user-defined attributes, no.  This is metadata for the programmer/lib to decode.

Obviously, compiler-defined attributes can.

-Steve

On 04/05/2012 08:05 PM, Andrei Alexandrescu wrote:
> On 4/5/12 12:44 PM, deadalnix wrote:
>> Le 05/04/2012 19:35, Walter Bright a écrit :
>>> On 4/5/2012 5:00 AM, Manu wrote:
>>>> C# and Java both have attributes, following these established design
>>>> patterns, I
>>>> don't think there should be any mystery over how they should be
>>>> implemented.
>>>
>>> At the Lang.NEXT conference over the last 3 days, I was able to talk to
>>> many smart people about attributes. But I did find some confusion - are
>>> they best attached to the variable/function (i.e. "storage class"), or
>>> attached to the type ("type constructor")? I think the former. Attaching
>>> it to the type leads to all sorts of semantic issues.
>>>
>>> From your list of uses, it looks like attaching it to the variable or
>>> function is an apropos solution.
>>
>> They should be attached to declarations.
>
> The question was whether the declaration affects the type of the
> declared or not.
>
> Andrei

Ideally it would be powerful enough to allow changing the type, but most applications probably want the type to stay the same.

On 4/5/2012 11:32 AM, Timon Gehr wrote:
> Ideally it would be powerful enough to allow changing the type, but most
> applications probably want the type to stay the same.

Having it perturb the type implies a huge swamp of how that affects the semantics. You've got overloading, name mangling, type inference, implicit conversions, covariance, etc.

All I can say is I see no way that can work with user defined semantics.