On 2013-01-04 21:33, 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.
>
> Since there's no runtime component, then aside from carrying a tuple and
> some information forward at compile-time, what else can it do? How would
> you use it? Are there any special tuple formats that give information to
> automatically be included/compiled into the structs/classes without
> having to resort to mixins?

It could be used for serialization, for example. Have a look at my serialization library, Orange.

http://dl.dropbox.com/u/18386187/orange_docs/orange.serialization.Serializable.html

Look at the "NonSerialized" template, that could now be replaced by a UDA. Like this:

class Foo
{
    int a;
    @NonSerialized int b; // will not be (de)serialized
}

-- 
/Jacob Carlborg

Am Fri, 04 Jan 2013 21:33:03 +0100
schrieb "Era Scarecrow" <rtcvb32@yahoo.com>:

> On Friday, 4 January 2013 at 15:45:21 UTC, Philippe Sigaud wrote:
> > User Defined Attributes (UDA) are compile time expressions that can be attached to a declaration. These attributes can then be queried, extracted, and manipulated at compile time. There is no runtime component to them.
> 
>   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.

Clojure uses its metadata (attached to values, though, not declaration) to put documentation strings there.

That's quite doable with D:

@(doc("This function does.... "))
auto foo()
{ ... }

I'm also interested in tagging data:

@(Sorted!(withThisFun)) someRange ...
@(Ranged(0.0, 1.0)) someRange ...

or:

@Validated SQLQuery query;

On 2013-01-05 15:13, Philippe Sigaud wrote:
>
> Clojure uses its metadata (attached to values, though, not declaration)
> to put documentation strings there.
>
> That's quite doable with D:
>
> @(doc("This function does.... "))
> auto foo()
> { ... }
>
> I'm also interested in tagging data:
>
> @(Sorted!(withThisFun)) someRange ...
> @(Ranged(0.0, 1.0)) someRange ...

Just for the record, the extra parentheses are not needed:

@doc("This function does.... ") auto foo () {  }
@Sorted!(withThisFun) someRange ...

-- 
/Jacob Carlborg

On Sat, Jan 5, 2013 at 6:00 PM, Jacob Carlborg <doob@me.com> wrote:

> Just for the record, the extra parentheses are not needed:
>
> @doc("This function does.... ") auto foo () {  }
> @Sorted!(withThisFun) someRange ...


Good to know. I tested it with basic values and this fails:

@"hello" int i;
@3 inj j;

Worth a bug report?

As a complement, multiple @'s are possible:

@("hello") @(3) int j;


And another complement:

struct S {}

@S S s; is possible.

But

@int S s;

is not

So user-defined types are OK, but not basic types. Looks like a
parsing/grammar problem for me, since attribute tuple sure should be able
to store built-in types.
Another bug report?

On 2013-01-05 19:54, Philippe Sigaud wrote:

> Good to know. I tested it with basic values and this fails:
>
> @"hello" int i;
> @3 inj j;
>
> Worth a bug report?

No, that's by design. When I added that syntax first but I was asked to change it to only accept call expressions. Have a look at the grammar:

https://dl.dropbox.com/u/18386187/attribute.html#uda

> As a complement, multiple @'s are possible:
>
> @("hello") @(3) int j;

Yes, that's legal and is supposed to be. Have a look at Walters original announcement:

http://forum.dlang.org/thread/k7afq6$2832$1@digitalmars.com

enum EEE = 7;
["hello"] struct SSS { }
[3] { [4][EEE][SSS] int foo; }

With the correct syntax that becomes:

enum EEE = 7;
@("hello") struct SSS { }
@(3) { @(4) @(EEE) @(SSS) int foo; }

Or:

@(3) { @(4) @EEE @SSS int foo; }

> And another complement:
>
> struct S {}
>
> @S S s; is possible.
> But
>
> @int S s;
>
> is not

That is not supposed to be legal (see above), but this might be:

@(int) S s;

Does that work?

> So user-defined types are OK, but not basic types. Looks like a
> parsing/grammar problem for me, since attribute tuple sure should be
> able to store built-in types.
> Another bug report?

I'm not sure.

-- 
/Jacob Carlborg

>
> No, that's by design. When I added that syntax first but I was asked to change it to only accept call expressions.
>


>> @int S s;
>>
>> is not
>>
>
> That is not supposed to be legal (see above), but this might be:
>
> @(int) S s;
>
> Does that work?


No. It produces reams of error.



>  So user-defined types are OK, but not basic types. Looks like a
>> parsing/grammar problem for me, since attribute tuple sure should be
>> able to store built-in types.
>> Another bug report?
>>
>
> I'm not sure.


I find it strange that @MyType ... is OK, but not @3, when, at the same
time @(MyType) and @(3) are *both* OK.


Also, why is @("hello") and @(SomeType) authorized, but not @(int)?

One extreme or the other looks OK for me: either only user-defined types are authorized (no @int, no @3) or everything a tuple can hold is authorized (hence, @int). The latter is more in line with the D way.

Also, if parenthesis can be dropped, allow them to be dropped for anything that's a token long, as is done for template arguments. That seems coherent with the rest of the language.

On 1/5/2013 10:54 AM, Philippe Sigaud wrote:
> Another bug report?

This is as designed, not a bug. The attribute must start with a @( or @identifier. Not @keyword, @number, @string, @operator, etc.

If you want, file an enhancement request for more. But the design was deliberately restrictive for now.

On Sat, Jan 5, 2013 at 10:20 PM, Walter Bright <newshound2@digitalmars.com>wrote:

> On 1/5/2013 10:54 AM, Philippe Sigaud wrote:
>
>> Another bug report?
>>
>
> This is as designed, not a bug. The attribute must start with a @( or @identifier. Not @keyword, @number, @string, @operator, etc.
>

That, I can understand.

But why is @(MyType) accepted, whereas @(int) is not?

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.