Proposal: user defined attributes

[Steven Schveighoffer]

On Tue, 20 Mar 2012 12:16:41 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> On 3/20/12 11:09 AM, Steven Schveighoffer wrote:
>> On Tue, 20 Mar 2012 11:17:02 -0400, Andrei Alexandrescu
>> <SeeWebsiteForEmail at erdani.org> wrote:
>>> I'm afraid I disagree. A targeted language feature definitely makes a
>>> library approach inferior, by definition. But adding features is
>>> cheating, like printing money is for a government: very tempting, with
>>> apparently good short-term benefits, but with devastating cumulative
>>> effects.
>>
>> Not exactly. We could all be writing code in assembly if "adding
>> features" was always caustic.
>
> This is trivializing my point. Please.

Well, then let's not compare the hyperinflation of the economy to adding a  
compiler feature.  There are certainly good reasons to add compiler  
features, without devastating cumulative effects.

>> What is nice about adding this feature is it provides a custom solution
>> to hooking the compiler's TypeInfo generation. We are setting up the
>> compiler to give us hooks so we *don't* have to extend the compiler
>> every time we want new reflection features.
>
> There is something nice about every new feature.

Yes, but this nicety is not just syntax sugar or a shortcut, it's adding a  
whole new opportunity of communication through the compile-time/runtime  
barrier.

I think Adam Ruppe's post on how he tried to use library code to  
accomplish this is quite telling.  The comparison to OO programming in C  
vs. C++/D seems quite appropriate.  And I've written Xt widgets, so I can  
vouch for how shitty it is to do OO programming in C.

>> One of the oft-requested features of D is reflection capability. The
>> answer is generally that we have compile-time reflection, which can
>> theoretically be used to build runtime reflection. However, the rebuttal
>> I always come back with is "yeah, but why should I build at runtime that
>> which is obvious at compile time?"
>
> I thought there were discussions that didn't add runtime overhead.

I haven't seen that.  Perhaps a link?

>> Note that one library that did attempt runtime reflection capability
>> (flectioned) does all this at runtime, and does some really funky shit,
>> like opening /proc/self/map on Linux, or requiring you to pass an
>> OPTLINK map file. I don't look at these as "innovations" as much as I do
>> as workarounds.
>
> Maybe there's a better approach than flectioned. Consider the language  
> is frozen solid. How would you solve problems with it?

I think the closest anyone has come is Jacob, with his orange library.   
Maybe he can respond to this point.

-Steve