On 2012-11-06 17:22, Walter Bright wrote:

> Consider that you can use a tuple generated elsewhere for a UDA:
>
> [tp] void foo();
>
> where tp is a tuple. You can even grab the attributes from another
> symbol, turn them into a tuple, and apply the tuple as an attribute to a
> new symbol. Tuples can, of course, be sliced and concatenated.
>
> In other words, by using tuples, you can "encapsulate" what the
> attributes expand to in the same way you can change target code by
> changing the definition of user defined types.

Then allow something like this:

@(tp)

Or

@foo(tp)

-- 
/Jacob Carlborg

On 11/6/2012 10:01 AM, David Nadlinger wrote:> On Tuesday, 6 November 2012 at 17:51:28 UTC, Walter Bright wrote:
>> On 11/6/2012 9:32 AM, David Nadlinger wrote:
>>> service Calculator {
>>>    i32 calculate(1:i32 a, 2:i32 b, 3:Op op)
>>
>> What does this mean? That 'a' is the first parameter and has type i32?
>
> It means that ›a‹ has type i32

Ok, but a type is not a UDA <g>.

> and is the parameter with ID 1. The parameter
> list could have also been (42:i32 a, 5:i32 b, 1:Op op). If no ids are specified,
> negative ones are auto-assigned by the compiler, starting from -1.

Why isn't 'a' the ID?

On 11/6/2012 9:52 AM, bearophile wrote:
> // Case3 (uncommon)
> void main() {
>      auto data = [0, 1, 2, 3];
>      foreach (@copy x; data)
>          writeln(++x);
> }

x is a value type, and it is already copied. And if you did want to copy it,

    foreach (x; data)
    {   auto copy = x;
        writeln(++copy);
    }

I don't see what the annotation buys you, even if it could be made to work.

On 2012-11-06 18:00, David Nadlinger wrote:

> Yes, it is nice to have a working prototype indeed. What is not so nice
> in my opinion, however, is that this first prototype straight to Git
> master, without any prior evaluation, at a time where the general goal
> is to stabilize the language.

Yes, very good point. I don't see why this hasn't been done before, it's dead easy. Just use:

$ git checkout -b uda
# code
$ git commit -a -m "Add support for user defined attributes"
$ git push origin uda

Walter, why aren't you using branches for these kind of things?

-- 
/Jacob Carlborg

On 11/6/2012 10:01 AM, Jacob Carlborg wrote:
> What's the issue with the name scoping system? That the user defined attributes
> will conflict with already existing attributes? You'll have the same problem
> with keywords. Perhaps that's why attributes where created, to have a new
> namespace for keywords. Even if they might not be the same internally for the
> compiler it's the same for the user/developer.

Then all UDAs must exist in some shared global name space, and scoping and encapsulation becomes like it is in C, i.e. every_body_writes_their_names_like_this and hopes it doesn't conflict with someone else's names.

On Tuesday, 6 November 2012 at 18:06:15 UTC, Walter Bright wrote:
> On 11/6/2012 10:01 AM, David Nadlinger wrote:> On Tuesday, 6 November 2012 at 17:51:28 UTC, Walter Bright wrote:
> >> On 11/6/2012 9:32 AM, David Nadlinger wrote:
> >>> service Calculator {
> >>>    i32 calculate(1:i32 a, 2:i32 b, 3:Op op)
> >>
> >> What does this mean? That 'a' is the first parameter and has
> type i32?
> >
> > It means that ›a‹ has type i32
>
> Ok, but a type is not a UDA <g>.

That was never my point. I could have also just said »Parameters to Thrift RPC methods have numerical IDs«, but I though a code example might be clearer. Apparently, I was wrong. ;)

> Why isn't 'a' the ID?
a is just a name used for documentation purposes – they show up in target language code generated by the Thrift compiler from the IDL file, for implementations which rely on code generation [1].

On the wire, all struct fields and method parameters are tagged with integer IDs, and those are actually what's used for (de-)serializations. This use of IDs is a common feature of »high-performance« RPC protocols designed to support interface evolution, e.g. Google's protobuf makes use of them as well.

David


[1] The compiler module for D only translates type and service definitions to D structs/interfaces, the rest happens using CTFE magic, which enables use of Thrift without writing .thrift files (in fact, they can be generated _from_ D code using CTFE). In theory, the compiler could be completely replaced using ImportStatements and CTFE, but I never got that out of the prototype stage due to compiler bugs.

On 2012-11-06 19:16, Walter Bright wrote:

> Then all UDAs must exist in some shared global name space, and scoping
> and encapsulation becomes like it is in C, i.e.
> every_body_writes_their_names_like_this and hopes it doesn't conflict
> with someone else's names.

No, what's the difference between this:

@every_body_writes_their_names_like_this int a;

And

["every_body_writes_their_names_like_this"] int a;

None.

-- 
/Jacob Carlborg

Le 06/11/2012 19:02, Walter Bright a écrit :
> On 11/6/2012 9:34 AM, dennis luehring wrote:
>> can't you please give us a bad-usage example why it is/should be
>> forbidden to
>> use UDA on parameters (and please - we are not talking about pure, in,
>> out and
>> stuff like that)
>
> I believe this is the wrong question. For a new feature, the question
> should be "why should it be included", not "why shouldn't it be included."
>

No. It is needed to annotate symbols, uses cases are numerous. Now, if an exception is added, the exception should be justified.

On Tuesday, 6 November 2012 at 18:16:15 UTC, Walter Bright wrote:
> Then all UDAs must exist in some shared global name space, and scoping and encapsulation becomes like it is in C, i.e. every_body_writes_their_names_like_this and hopes it doesn't conflict with someone else's names.

You are right, UDAs must definitely leverage D's module system for encapsulation/disambiguation. Use of string literals (which are intrinsically »global«) as annotations needs to be explicitly discouraged.

David

Le 06/11/2012 19:19, Jacob Carlborg a écrit :
> On 2012-11-06 19:16, Walter Bright wrote:
>
>> Then all UDAs must exist in some shared global name space, and scoping
>> and encapsulation becomes like it is in C, i.e.
>> every_body_writes_their_names_like_this and hopes it doesn't conflict
>> with someone else's names.
>
> No, what's the difference between this:
>
> @every_body_writes_their_names_like_this int a;
>
> And
>
> ["every_body_writes_their_names_like_this"] int a;
>
> None.
>

Let me suggest what have already been suggested by others :

@identifier(parameters)

identifier is resolved as any identifier is. It allow for disambiguation. It also allow for a lib to provide its own attributes types without colliding which other (it is easy to filter the tuple for attribute with the right type).