March 21, 2012
On 2012-03-21 17:00, Adam D. Ruppe wrote:
> On Wednesday, 21 March 2012 at 15:02:15 UTC, Jacob Carlborg wrote:
>> Here's my proposal:
>
> Ah yes, I think I did read that before.
>
> I'm not in love with the key=value or the explicit
> @attribute on the classes, which is the two biggest
> differences we have.
>
> The key=value is nice, but it isn't in the language today,
> so it'd be a bunch of special code in the @attribute parser
> in the compiler.
>
> If we were to have key=value syntax, I say we should do it
> generically (like C style struct initializers?) so it can
> work in regular code too, then pick it up naturally here.

Would "key: value" be possible. The syntax we have for AA literals?

> I'd prefer to use the existing language syntax in there
> so the implementation can literally be as simple as:
>
> if(token == TOKnote) {
> token.next();
> annotations ~= parseExpression();
> }
>
>
> D's existing struct syntax can handle arguments easily
> enough with the StructName("member", "member"); style.
> Reusing that here keeps the implementation simple,
> and it might be more flexible:
>
> enum MyNote = Something("with args", 2);

That would be nice.

> @note(MyNote) int foo;
> @note(MyNote) bool bar;

But I don't like the @note syntax. I really would like this:

@MyNote int foo;


> The other thing is @attribute struct {} rather than just
> struct {}. I don't any benefit to that. If I want to
> reuse a regular, runtime struct to store info at compile
> time, why shouldn't I be able to do that?

I just throw that in because Java has it. Don't know if it's needed or not. Java has a kind of special syntax for default values with annotations.

-- 
/Jacob Carlborg
March 21, 2012
On 3/21/12 12:06 PM, Jacob Carlborg wrote:
> On 2012-03-21 16:11, Andrei Alexandrescu wrote:
> I think the liability here is that b needs to appear in two places, once
>> in the declaration proper and then in the NonSerialized part. (A
>> possible advantage is that sometimes it may be advantageous to keep all
>> symbols with a specific attribute in one place.) A possibility would be
>> to make the mixin expand to the field and the metadata at once.
>
> Yes, but that just looks ugly:
>
> class Foo
> {
> int a;
> mixin NonSerialized!(int, "b");
> }
>
> That's why it's so nice with attributes.

Well if the argument boils down to nice vs. ugly, as opposed to possible vs. impossible - it's quite a bit less compelling.

Andrei


March 21, 2012
On Wed, 21 Mar 2012 13:47:56 -0400, Jacob Carlborg <doob@me.com> wrote:

> On 2012-03-21 17:00, Adam D. Ruppe wrote:

>> The other thing is @attribute struct {} rather than just
>> struct {}. I don't any benefit to that. If I want to
>> reuse a regular, runtime struct to store info at compile
>> time, why shouldn't I be able to do that?
>
> I just throw that in because Java has it. Don't know if it's needed or not. Java has a kind of special syntax for default values with annotations.

Really, the only requirement for an annotation expression should be that it's evaluated at compile time.

But we could see weird things with annotations if we don't specifically say what's an annotation and what is not.

For example:

// used as a normal datatype in most places
struct Point2d
{
  int X;
  int Y;
}

@Point2d int x; // ??
or
@note(Point2d) int x; // ??

In my proposal, I specified that the annotation can be applied only to module-level functions (normal or templated), and the result of those functions is what gets saved.  So with that capability, you should be able to store any CTFE-evaluatable struct:

@annotation auto makeAPoint() {Point2d p;  return p;}

@makeAPoint int x;

Which is as confusing as the above two examples, but at least *someone* declared it made sense to them ;)  Note that the @annotation function need not be stored in the EXE, it's only valid during CTFE.

I look at it similar to in C++ being able to throw any arbitrary type.  Sure, you can just avoid creating an exception type that wraps an int, but it may not make sense to anyone if you just throw an int.

-Steve
March 21, 2012
On 2012-03-21 17:27, F i L wrote:

> I'm not sure, you're understand of D's compiler-time structures is much
> better than mine. Serialization "attributes" are mostly used at runtime,
> so having mixing in a static enum *should* mean reflection upon the
> property at both runtime and compiletime.

I'm using the serialization attributes at compile time.

-- 
/Jacob Carlborg
March 21, 2012
On 2012-03-21 18:22, F i L wrote:
> Jacob Carlborg wrote:
>> Only the name of the variables are necessary in my serialization library.
>
> Wouldn't mixing in an enum be more useful? You could use it at compile
> time that way.

I'm using a static const variable because it's compatible with D1. It still works at compile time.

-- 
/Jacob Carlborg
March 21, 2012
On 2012-03-21 19:32, Andrei Alexandrescu wrote:

> Well if the argument boils down to nice vs. ugly, as opposed to possible
> vs. impossible - it's quite a bit less compelling.

No, that's just one part on the problem. Read Adam D. Ruppe's posts in this thread, for example.

-- 
/Jacob Carlborg
March 21, 2012
On 2012-03-21 19:32, Steven Schveighoffer wrote:

> In my proposal, I specified that the annotation can be applied only to
> module-level functions (normal or templated), and the result of those
> functions is what gets saved. So with that capability, you should be
> able to store any CTFE-evaluatable struct:
>
> @annotation auto makeAPoint() {Point2d p; return p;}
>
> @makeAPoint int x;

Does "@makeAPoint int x;" expand to "Point2d p; return p;"?

-- 
/Jacob Carlborg
March 21, 2012
On Wed, 21 Mar 2012 17:10:06 -0400, Jacob Carlborg <doob@me.com> wrote:

> On 2012-03-21 19:32, Steven Schveighoffer wrote:
>
>> In my proposal, I specified that the annotation can be applied only to
>> module-level functions (normal or templated), and the result of those
>> functions is what gets saved. So with that capability, you should be
>> able to store any CTFE-evaluatable struct:
>>
>> @annotation auto makeAPoint() {Point2d p; return p;}
>>
>> @makeAPoint int x;
>
> Does "@makeAPoint int x;" expand to "Point2d p; return p;"?

What I envision is that @makeAPoint translates to the CTFE engine calling makeAPoint with no arguments.  This returns a Point2d default initialized.  That result is stored in the TypeInfo (or ModuleInfo) in the appropriate location for the 'x' member.

Then you can query this using runtime or compile-time functions later on, using the name "makeAPoint".

So in effect, you can use any struct or type that can be constructed at compile-time.  But it allows you to specify which types (and in which ways they can be constructed) can be used as annotations.  It also allows you to name the way that type is used.

It also could give you a way to use the same type for different annotations, discernible by name.

-Steve
March 21, 2012
On 2012-03-21 22:32, Steven Schveighoffer wrote:

> What I envision is that @makeAPoint translates to the CTFE engine
> calling makeAPoint with no arguments. This returns a Point2d default
> initialized. That result is stored in the TypeInfo (or ModuleInfo) in
> the appropriate location for the 'x' member.
>
> Then you can query this using runtime or compile-time functions later
> on, using the name "makeAPoint".

That sounds like a pretty good idea. Many good ideas have popped up in this thread. It's hard to know which would work best.

-- 
/Jacob Carlborg
March 21, 2012
Le 21/03/2012 17:22, Andrei Alexandrescu a écrit :
> On 3/21/12 11:17 AM, Timon Gehr wrote:
>> On 03/20/2012 10:36 PM, deadalnix wrote:
>>> Even the propagation of pure, @safe, nothrow and const that has been
>>> discussed recently can be done with that feature.
>>>
>>
>> I'm sceptical. How would that work exactly?
>
> I, too, am highly skeptical. For one thing these attributes must be made
> part of the type and have deep connections with code semantics.
>
> Andrei

That is the point. The property must be able to manipulate what is qualified. This is the point of AOP.

If you let me some time, I could write a proposal. BTW, this is probably something we don't want to rush in, but I'm sure it definitively worth it.

Have you seen what a project like lombok can do ?