The only way would be what you suggest:
>>
>> - extract the attributes from the internal i
>> - store them in a specially-crafted struct
>> - return that
>> - in the external code, catch the returned struct
>> - extract the artificially stored attributes
>> - generate a new value with the same attributes.
>>
>
> You can perhaps encapsulate this in a mixin?


That would mean two mixins, one internal and one external. Plus, that means every function where I want to propagate UDA has to be crafted exactly for this need.

This is a drag. It seems natural to me that

int foo(int i) { return i;}

should forward i attributes. But maybe I need a shift my way to think about attributes. They are attached to declarations, not values...

That's too bad, because declaring UDA is simple, and receiving them with arguments is easy also. There is a fundamental imbalance in having having propagating attributes through functions so difficult.

On 2013-01-06 15:25, Philippe Sigaud wrote:

> That would mean two mixins, one internal and one external. Plus, that
> means every function where I want to propagate UDA has to be crafted
> exactly for this need.
>
> This is a drag. It seems natural to me that
>
> int foo(int i) { return i;}
>
> should forward i attributes. But maybe I need a shift my way to think
> about attributes. They are attached to declarations, not values...

Exactly.

> That's too bad, because declaring UDA is simple, and receiving them with
> arguments is easy also. There is a fundamental imbalance in having
> having propagating attributes through functions so difficult.

Yeah, if you want to work with UDA's you need to work with symbols, not values or types. If you want to pass a symbol, including its UDA, you need to pass it as an alias:

void foo (alias symbol) ()
{
    // access UDA of symbol
}

@(3) int a;
foo!(a);

-- 
/Jacob Carlborg

On 1/6/13 9:25 AM, Philippe Sigaud wrote:
> That's too bad, because declaring UDA is simple, and receiving them with
> arguments is easy also. There is a fundamental imbalance in having
> having propagating attributes through functions so difficult.

<brokenrecord>For designing attributes that navigate with types templates would be the solution of choice.</brokenrecord>

Andrei

Andrei Alexandrescu:

> <brokenrecord>For designing attributes that navigate with types templates would be the solution of choice.</brokenrecord>

There's an interesting cognitive impercetion phenomena here, that's worth studying and not ignoring. From the little evidence here, it seems that D programmers want to use UDAs instead of templates for those purposes. Possibly because UDAs look more fit (despite you rightfully say they aren't).

Bye,
bearophile

On Saturday, 5 January 2013 at 11:57:39 UTC, Johannes Pfau wrote:
> Era Scarecrow wrote:
>> This is sorta like tuples; But from the brief summaries I cannot fully understand how or where they would be used. I understand some attributes can be made and added that some compilers may use (@noreturn as an example), but outside of the compiler I'd need an example of how to make use of them.
>
> One example is std.benchmark. It currently detects if a function is a benchmark function by checking the name: void benchmark_stdio();
>
> With UDAs we can do this:
> @benchmark stdio();
> or
> @benchmark("Benchmarking stdio reads, using xKB buffer") benchStdio1();
>
> There's still the issue of "How do I get all the declarations in a module (/ the applications)", but UDAs already help a lot.

 Yes I understand how you can attach some information using a UDA, but that still doesn't tell me _how to use_ it. Unless you can somehow locate & manipulate/use/pass the information around than it's no more than a comment that isn't removed immediately.


 Slightly off topic: I get the feeling that with the questions of current specs, the large number of changes (few hugely breaking) and outdated TDPL the language documentation needs a good through update. Perhaps a TDPL v2 regarding changes to the language; Rather than replacing TDPL, it instead it compliments it. And when phobos is more mature and isn't going to be changing then an API/reference book for it would likely be a third book.

On Sun, Jan 6, 2013 at 3:58 PM, Andrei Alexandrescu < SeeWebsiteForEmail@erdani.org> wrote:

> On 1/6/13 9:25 AM, Philippe Sigaud wrote:
>
>> That's too bad, because declaring UDA is simple, and receiving them with arguments is easy also. There is a fundamental imbalance in having having propagating attributes through functions so difficult.
>>
>
> <brokenrecord>For designing attributes that navigate with types templates would be the solution of choice.</brokenrecord>


Care to show a small example?

I tried 1-2 years ago. With alias this, that's partially acceptable. I just
remember it was a bit burdensome tp use and dumped it.
But OK, if UDA do not do that, then I'll go back to templates. Since alias
this become better, maybe something can be done here.

On Sun, Jan 6, 2013 at 3:29 PM, Jacob Carlborg <doob@me.com> wrote:

>
> Yeah, if you want to work with UDA's you need to work with symbols, not values or types. If you want to pass a symbol, including its UDA, you need to pass it as an alias:
>

That was the explanation I needed: UDA are attached to symbols. Now that's, clearer ;)

Hmm, did anyone try to put attribute before a function overload and not another?

Ca

(PS: symbols, except modules, because they are second-class citizens)

Hmm, did anyone try to put attribute before a function overload and not
> another?
>



> Ca
>

Damn tab.

Can attributes be defined by templates arguments?


@(T) class C(T) : T { }

Answer: no. OK.

On 01/04/2013 11:43 PM, Philippe Sigaud wrote:
> On Fri, Jan 4, 2013 at 9:58 PM, Walter Bright
> <newshound2@digitalmars.com <mailto:newshound2@digitalmars.com>> wrote:
>
>
>     Module declarations aren't declarations.
>
>
> Great quote :)
>
>

Walter often argues in terms of DMD implementation details.

...
struct ModuleDeclaration
{
    Identifier *id;
...

On Saturday, 5 January 2013 at 22:14:47 UTC, Walter Bright wrote:
> On 1/5/2013 2:06 PM, Philippe Sigaud wrote:
>> But why is @(MyType) accepted, whereas @(int) is not?
>
> Because it's looking for an expression inside the parents, and int is not an expression.

And mytype is an expression ?????