On 11/6/2012 10:45 AM, David Nadlinger wrote:
> This doesn't put the @-syntax out of the game, though: @attribute could just be
> equivalent to @(attribute) and look up "attribute" in the local scope, following
> the usual rules. This would look much better than the bracket syntax, at least
> in my opinion, and avoid confusion with array literals.

[ ] vs @( ) is a completely separate issue.

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

> You're right, there is none. That's why using type names as attributes
> is more scalable and robust.

Then why allow it? Actually the more I think about it the more I think you're right in that it's better to use a proper symbol or type name. But I still don't like the syntax.

> I understand your desire to have attributes be implicitly declared, but
> I think that implicit declarations have historically been seductive, and
> much later were realized to be a mistake. This pattern has happened over
> and over :-)

Actually I don't. I was just trying to stay close to your implementation. This is one of my proposals, from a one the threads you linked to:

http://www.digitalmars.com/d/archives/digitalmars/D/Proposal_user_defined_attributes_161624.html#N161742

In that proposal you have to clearly define an attribute, like:

attribute class serializable { }

attribute class name
{
    string fieldName;
}

@serializable class FooBar
{
    @name("foo") int bar;
}

"serializable" and "name" would be symbols you can import have the same name look up rules any other symbol.

-- 
/Jacob Carlborg

On 2012-11-06 19:45, David Nadlinger wrote:

> This doesn't put the @-syntax out of the game, though: @attribute could
> just be equivalent to @(attribute) and look up "attribute" in the local
> scope, following the usual rules. This would look much better than the
> bracket syntax, at least in my opinion, and avoid confusion with array
> literals.

Exactly, good point.

-- 
/Jacob Carlborg

On 2012-11-06 19:24, David Nadlinger wrote:

> 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.

Then why allow it in the first place?

-- 
/Jacob Carlborg

On Tuesday, 6 November 2012 at 19:12:54 UTC, Walter Bright wrote:

> As for the return value attributes, I think that can be handled by attributing the function symbol itself, as it can only have one return type.

Theoretically there might be cases requiring an attribute of the same class both on the function and on the return value. Then differentiation of function and return value attributes would be necessary. Anybody has an example?

On 2012-11-06 19:42, Max Samukha wrote:

> C# allows custom attributes on function parameters, including the return
> value. Actually, it allows custom meta-data everywhere. See a use case
> here
> http://msdn.microsoft.com/en-us/library/system.runtime.interopservices.marshalasattribute.aspx.
>
> I believe Java does the same.

Yes it does:

http://docs.oracle.com/javase/1.5.0/docs/guide/language/annotations.html

You need to specify the target tough, like declaration of an annotation:

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface Test { }

-- 
/Jacob Carlborg

On Tuesday, 6 November 2012 at 19:36:18 UTC, Walter Bright wrote:
> [ ] vs @( ) is a completely separate issue.

Yes, you're right, the issues are not related. I just wanted to share the idea, and your dm.D thread didn't exist back then.

David

On 2012-11-06 20:44, David Nadlinger wrote:

> Yes, you're right, the issues are not related. I just wanted to share
> the idea, and your dm.D thread didn't exist back then.
>
> David

Oh, didn't notice until now. I've already added my vote.

-- 
/Jacob Carlborg

On 11/6/2012 11:42 AM, Max Samukha wrote:> Theoretically there might be cases requiring an attribute of the same class both
> on the function and on the return value. Then differentiation of function and
> return value attributes would be necessary. Anybody has an example?

Not a problem, as you'd search the tuple for the attribute that matters anyway.

On Tuesday, 6 November 2012 at 19:43:54 UTC, Jacob Carlborg wrote:
>
> You need to specify the target tough, like declaration of an annotation:
>
> @Retention(RetentionPolicy.RUNTIME)
> @Target(ElementType.METHOD)
> public @interface Test { }

Yep, C# attributes can be restricted to specific targets as well.