www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DIP6: Attributes

reply Ary Borenszweig <ary esperanto.org.ar> writes:
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6
Aug 01 2009
next sibling parent Ary Borenszweig <ary esperanto.org.ar> writes:
Ary Borenszweig escribió:

 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6


Ouch. I meant: DIP6: Annotations.
Aug 01 2009
prev sibling next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sat, Aug 01, 2009 at 04:29:28PM -0300, Ary Borenszweig wrote:

 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6


What's the difference between this and a keyword? It seems to be a keyword
with a different name.

For this annotation thing to be really useful, I'd think it should be well,
dynamic for lack of a better word.

You can just list them on an item, then inspect them later in templates:

 magic int a;
[...]

auto annotations = __traits(annotations, a);

assert(annotations[0] == "magic"); // now you can do whatever with this


I wished I had something like this before, but I forgot why....



But if you aren't proposing something like that being possible, then what's
the point of the   to a keyword? It doesn't seem to be any different.


-- 
Adam D. Ruppe
http://arsdnet.net
Aug 01 2009
parent Ary Borenszweig <ary esperanto.org.ar> writes:
Adam D. Ruppe escribió:

 On Sat, Aug 01, 2009 at 04:29:28PM -0300, Ary Borenszweig wrote:

 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6


 
 What's the difference between this and a keyword? It seems to be a keyword
 with a different name.


A keyword means changing the lexer, the parser and the semantic 
analysis. Annotations means only changing the semantic analysis (ok, 
changing the lexer and parser also, but just the first time to implement 
annotations). And if the first stage is implemented, what you describe 
below could also be implemented.

As the DIP says, the advantage is also reducing the huge amount of 
keywords that exist now in the language.


 For this annotation thing to be really useful, I'd think it should be well,
 dynamic for lack of a better word.
 
 You can just list them on an item, then inspect them later in templates:
 
  magic int a;
 [...]
 
 auto annotations = __traits(annotations, a);
 
 assert(annotations[0] == "magic"); // now you can do whatever with this
 
 
 I wished I had something like this before, but I forgot why....
 
 
 
 But if you aren't proposing something like that being possible, then what's
 the point of the   to a keyword? It doesn't seem to be any different.


I could have included that in the DIP. But you have to start with small 
things, simple things, and evolve from that point. The DIP is just about 
how to start introducing annotations in the language with minimal 
changes to what exists now.
Aug 01 2009
prev sibling next sibling parent aarti_pl <aarti interia.pl> writes:
Ary Borenszweig pisze:

 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6


Nice! This proposal seems to be really better (more general and 
extensible) than any property proposal before.

BR
Marcin Kuszczak
(aarti_pl)
Aug 01 2009
prev sibling next sibling parent reply Tim Matthews <tim.matthews7 gmail.com> writes:
On Sat, 01 Aug 2009 16:29:28 -0300
Ary Borenszweig <ary esperanto.org.ar> wrote:


 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6


Are pragmas not already here for this?
Aug 01 2009
parent Robert Fraser <fraserofthenight gmail.com> writes:
Tim Matthews wrote:

 On Sat, 01 Aug 2009 16:29:28 -0300
 Ary Borenszweig <ary esperanto.org.ar> wrote:
 

 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6


 
 Are pragmas not already here for this? 


Nope, they're for compiler-specific extensions
Aug 01 2009
prev sibling next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Ary Borenszweig wrote:

 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6


I think annotations are a good idea, but turning keywords already in the 
language into annotations seems kinda pointless & would kill backwards 

annotations -- and with good reason.

IMO, the focus of annotations should be mostly on things _external_ to 
the compiler. So, serializability, thread safety, etc. Really, I think 
annotations should be for compile-time reflection (so like someone else 
said __traits(annotations, symbol) should return a tuple of annotation 
structs.
Aug 01 2009
next sibling parent Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
Robert Fraser wrote:

 Ary Borenszweig wrote:

 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6


 
 I think annotations are a good idea, but turning keywords already in the
 language into annotations seems kinda pointless & would kill backwards

 annotations -- and with good reason.
 
 IMO, the focus of annotations should be mostly on things _external_ to
 the compiler. So, serializability, thread safety, etc. Really, I think
 annotations should be for compile-time reflection (so like someone else
 said __traits(annotations, symbol) should return a tuple of annotation
 structs.


Seconded. Annotations sound like a useful feature especially if they can
be created and manipulated by the programmer, which would require
syntactic distinction. I never did much care for java's annotation
syntax, but I do think turning most if not all of the keywords mentioned
into annotations is a good idea, at least behind the scenes.

Off the top of my head, it could solve the function <-> delegate ref
parameter problem.
Aug 01 2009
prev sibling parent reply Max Samukha <spambox d-coding.com> writes:
On Sat, 01 Aug 2009 15:24:26 -0700, Robert Fraser
<fraserofthenight gmail.com> wrote:


Ary Borenszweig wrote:

 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6


I think annotations are a good idea, but turning keywords already in the 
language into annotations seems kinda pointless & would kill backwards 

annotations -- and with good reason.

IMO, the focus of annotations should be mostly on things _external_ to 
the compiler. So, serializability, thread safety, etc. Really, I think 
annotations should be for compile-time reflection (so like someone else 
said __traits(annotations, symbol) should return a tuple of annotation 
structs.


Please not a tuple of structs but a tuple of tuples. One should be
able to specify types and aliases as annotation parameters.
Aug 02 2009
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Max Samukha wrote:

 On Sat, 01 Aug 2009 15:24:26 -0700, Robert Fraser
 <fraserofthenight gmail.com> wrote:
 

 Ary Borenszweig wrote:

 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6


 I think annotations are a good idea, but turning keywords already in the 
 language into annotations seems kinda pointless & would kill backwards 

 annotations -- and with good reason.

 IMO, the focus of annotations should be mostly on things _external_ to 
 the compiler. So, serializability, thread safety, etc. Really, I think 
 annotations should be for compile-time reflection (so like someone else 
 said __traits(annotations, symbol) should return a tuple of annotation 
 structs.


 
 Please not a tuple of structs but a tuple of tuples. One should be
 able to specify types and aliases as annotation parameters.


I wish that's work, but Tuples flatten themselves.
Aug 02 2009
parent Max Samukha <spambox d-coding.com> writes:
On Sun, 02 Aug 2009 07:54:49 -0700, Robert Fraser
<fraserofthenight gmail.com> wrote:


Max Samukha wrote:

 On Sat, 01 Aug 2009 15:24:26 -0700, Robert Fraser
 <fraserofthenight gmail.com> wrote:
 

 Ary Borenszweig wrote:

 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6


 I think annotations are a good idea, but turning keywords already in the 
 language into annotations seems kinda pointless & would kill backwards 

 annotations -- and with good reason.

 IMO, the focus of annotations should be mostly on things _external_ to 
 the compiler. So, serializability, thread safety, etc. Really, I think 
 annotations should be for compile-time reflection (so like someone else 
 said __traits(annotations, symbol) should return a tuple of annotation 
 structs.


 
 Please not a tuple of structs but a tuple of tuples. One should be
 able to specify types and aliases as annotation parameters.


I wish that's work, but Tuples flatten themselves.


Yes, but we can define a non-flattening tuple:

template CannedTuple(A...)
{
    alias A tuple;
}

Then we can have tuples of tuples:

alias Tuple!(CannedTuple!(...), CannedTuple!(...), ...) annotations;

// I guess, the first element should be the annotation name?
enum annotationName = annotations[0].tuple[0]; 

We already can emulate custom attributes with mixins, though this
requires template trickery that sometimes is overwhelming. So some
syntax sugar would be welcome.
Aug 02 2009
prev sibling next sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Ary Borenszweig, el  1 de agosto a las 16:29 me escribiste:

 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6


Please, try to post at least the abstract of the DIP with the link, so
people can easily know what is it about =)

And when writing a DIP, try to make the abstract a little more
descriptive. From an abstract you should be able to tell what the DIP is
about (in this case explain what an annotation is at least). A oneliner is
not good enough, that's just a title, not an abstract. If it's too hard
to explain, try to provide a link to somewhere else where the terms are
described.

The rationale can be a little more descriptive too. What are the
advantages of removing keywords for example? Use NG posts links if you
have some problems documented there, for example.

Try not to explain your opinion in DIPs. They are not NG posts, they
should provide facts and be as objective as possible. Even when that's
pretty hard, saying "I prefer Java's one because ..." is excessively
subjective. Avoid doing that. You can express the same by saying something
like "Java syntax has the advantage of ..." for example.

A section called "Other thoughts" is not very serious either. If you are
not yet convinced about something in the DIP, post it in the announcement
post in the NG so it can be discussed and added later to the DIP when the
idea is in better shape.

Please, don't take this personally, I just want DIPs to be high quality,
otherwise they will never be taken seriously. =)

I've added this information in a Recommendations subsection to the DIP1,
see:
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP1#Recommendations

I'll address the DIP itself in another post ;)

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
HOMBRE DESNUDO AMENAZA A LOS VECINOS CON UNA "KATANA" DESDE SU BALCON
	-- Crónica TV
Aug 01 2009
next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Leandro Lucarella, el  1 de agosto a las 20:28 me escribiste:

 Ary Borenszweig, el  1 de agosto a las 16:29 me escribiste:

 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6


 
 Please, try to post at least the abstract of the DIP with the link, so
 people can easily know what is it about =)


BTW, you forgot to link the DIP to the DIPs index:
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs

It's linked now... =)

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Home, home again.
I like to be here when I can.
When I come home cold and tired
It's good to warm my bones beside the fire.
Aug 01 2009
prev sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Leandro Lucarella escribió:

 Ary Borenszweig, el  1 de agosto a las 16:29 me escribiste:

 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6


 
 Please, try to post at least the abstract of the DIP with the link, so
 people can easily know what is it about =)
 
 And when writing a DIP, try to make the abstract a little more
 descriptive. From an abstract you should be able to tell what the DIP is
 about (in this case explain what an annotation is at least). A oneliner is
 not good enough, that's just a title, not an abstract. If it's too hard
 to explain, try to provide a link to somewhere else where the terms are
 described.
 
 The rationale can be a little more descriptive too. What are the
 advantages of removing keywords for example? Use NG posts links if you
 have some problems documented there, for example.
 
 Try not to explain your opinion in DIPs. They are not NG posts, they
 should provide facts and be as objective as possible. Even when that's
 pretty hard, saying "I prefer Java's one because ..." is excessively
 subjective. Avoid doing that. You can express the same by saying something
 like "Java syntax has the advantage of ..." for example.
 
 A section called "Other thoughts" is not very serious either. If you are
 not yet convinced about something in the DIP, post it in the announcement
 post in the NG so it can be discussed and added later to the DIP when the
 idea is in better shape.
 
 Please, don't take this personally, I just want DIPs to be high quality,
 otherwise they will never be taken seriously. =)
 
 I've added this information in a Recommendations subsection to the DIP1,
 see:
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP1#Recommendations
 
 I'll address the DIP itself in another post ;)


Hola Leandro,

I've updated the DIP page with your recommendations. I agree with all of 
them.

Please, can someone (pst, bearophile) check that what I found as 
decorators in Pyhton are what we are calling annotations here? Thanks!
Aug 01 2009
next sibling parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
Ary Borenszweig wrote:

 Leandro Lucarella escribió:

 Ary Borenszweig, el  1 de agosto a las 16:29 me escribiste:

 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6


 Please, try to post at least the abstract of the DIP with the link, so
 people can easily know what is it about =)

 And when writing a DIP, try to make the abstract a little more
 descriptive. From an abstract you should be able to tell what the DIP is
 about (in this case explain what an annotation is at least). A
 oneliner is
 not good enough, that's just a title, not an abstract. If it's too hard
 to explain, try to provide a link to somewhere else where the terms are
 described.

 The rationale can be a little more descriptive too. What are the
 advantages of removing keywords for example? Use NG posts links if you
 have some problems documented there, for example.

 Try not to explain your opinion in DIPs. They are not NG posts, they
 should provide facts and be as objective as possible. Even when that's
 pretty hard, saying "I prefer Java's one because ..." is excessively
 subjective. Avoid doing that. You can express the same by saying
 something
 like "Java syntax has the advantage of ..." for example.

 A section called "Other thoughts" is not very serious either. If you are
 not yet convinced about something in the DIP, post it in the announcement
 post in the NG so it can be discussed and added later to the DIP when the
 idea is in better shape.

 Please, don't take this personally, I just want DIPs to be high quality,
 otherwise they will never be taken seriously. =)

 I've added this information in a Recommendations subsection to the DIP1,
 see:
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP1#Recommendations


 I'll address the DIP itself in another post ;)


 
 Hola Leandro,
 
 I've updated the DIP page with your recommendations. I agree with all of
 them.
 
 Please, can someone (pst, bearophile) check that what I found as
 decorators in Pyhton are what we are calling annotations here? Thanks!


They aren't. Decorators are deep crazy magic. As I recall,

 mydecorator
def myfunc(argsnjunk):
    pass

transforms all calls to myfunc to a call to a function you defined
somewhere named mydecorator, which takes a function and its arguments as
parameters and returns a function which is expected to call the function
with its arguments. Then the returned function gets called.

Very nifty for a wide variety of things.
Aug 01 2009
parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Sat, Aug 1, 2009 at 11:27 PM, Ellery
Newcomer<ellery-newcomer utulsa.edu> wrote:

 They aren't. Decorators are deep crazy magic. As I recall,

  mydecorator
 def myfunc(argsnjunk):
 =A0 =A0pass

 transforms all calls to myfunc to a call to a function you defined
 somewhere named mydecorator, which takes a function and its arguments as
 parameters and returns a function which is expected to call the function
 with its arguments. Then the returned function gets called.


Close, but not quite.  What instead happens is that this gets
transformed into something like:

myfunc =3D mydecorator()(lambda(argsnjunk): pass)

That is, mydecorator() returns a callable; that callable takes the
function that you're defining as its argument, potentially modifies or
transforms it, then returns either the same function or anything else,
which is finally stored in myfunc.  Calls to myfunc are not
transformed at all; all that has happened is that the decorator has
intercepted the function definition, and might have replaced the
original function with a new one.
Aug 01 2009
prev sibling parent Leandro Lucarella <llucax gmail.com> writes:
Ary Borenszweig, el  2 de agosto a las 00:07 me escribiste:

 Leandro Lucarella escribió:

Ary Borenszweig, el  1 de agosto a las 16:29 me escribiste:

http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6


Please, try to post at least the abstract of the DIP with the link, so
people can easily know what is it about =)
And when writing a DIP, try to make the abstract a little more
descriptive. From an abstract you should be able to tell what the DIP is
about (in this case explain what an annotation is at least). A oneliner is
not good enough, that's just a title, not an abstract. If it's too hard
to explain, try to provide a link to somewhere else where the terms are
described.
The rationale can be a little more descriptive too. What are the
advantages of removing keywords for example? Use NG posts links if you
have some problems documented there, for example.
Try not to explain your opinion in DIPs. They are not NG posts, they
should provide facts and be as objective as possible. Even when that's
pretty hard, saying "I prefer Java's one because ..." is excessively
subjective. Avoid doing that. You can express the same by saying something
like "Java syntax has the advantage of ..." for example.
A section called "Other thoughts" is not very serious either. If you are
not yet convinced about something in the DIP, post it in the announcement
post in the NG so it can be discussed and added later to the DIP when the
idea is in better shape.
Please, don't take this personally, I just want DIPs to be high quality,
otherwise they will never be taken seriously. =)
I've added this information in a Recommendations subsection to the DIP1,
see:
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP1#Recommendations
I'll address the DIP itself in another post ;)


 
 Hola Leandro,
 
 I've updated the DIP page with your recommendations. I agree with all of
 them.


Thanks!

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
"Somos testigos de Jaimito, venimos a traer la salvación, el mundo va a
desaparecer, somos testigos de Jaimito!". Nos enyoguizamos... Así que
"somos testigos"? Te dejo el culo hecho un vino, y la conch'itumá, y la
conch'itumá!
	-- Sidharta Kiwi
Aug 02 2009
prev sibling next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Ary Borenszweig, el  1 de agosto a las 16:29 me escribiste:

 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6


I really think that D should support some kind of annotations. I think
it's a good idea to add them in stages. I could add that in the first
stage, old-style attributes/whatever (override, deprecated, etc.) should
be accepted too (i.e. without the leading  ). Then people complaining
about backward compatibility can be happy (me included; hey! I'll add them
to D1.1 too! ;). New syntax can make use of annotations though (hello
properties!).

I think annotations in D can reach their peak of utility when AST macros
get implemented. I think it would be great being able to "register"
annotation handlers to the compiler to do arbitrary transformations to the
code. You could even move a big part of the compiler implementation to
library code using annotations and AST macros. But this have to come in
other stages for sure.

I think changing the FE to allow annotation syntax wouldn't be very hard
(I'm guessing, I never hacked the DMDFE myself). Maybe someone who played
with the FE can make a quick patch as a proof of concepts, even if the
implementation ignores the annotations completely for now it can be a good
start.

I think the "Other thoughts" section should be official part of the
proposal if there is any intention to move most of the current attribute
keywords to annotations.

About the version(X) {} else {}, first, version(!X) could be supported as
an ugly hack =P. A more generic approach could be to support annotations
returns. Annotations could return void (in which case the else statement
is a *semantic* error) or bool (in which case the else statement is
supported). The problem with this is that statements should be target for
annotations too, so one can do:

 deprecated
void foo()
{
	 version(Foo) writeln("foo");
}

Maybe this one should be delayed for a second stage of annotations =)

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
CHINO ATRAPA COTORRAS
	-- Crónica TV
Aug 01 2009
prev sibling next sibling parent Chad J <chadjoan __spam.is.bad__gmail.com> writes:
Ary Borenszweig wrote:

 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6


I like this.  Metadata is a very useful thing.
Aug 02 2009
prev sibling next sibling parent reply grauzone <none example.net> writes:
Ary Borenszweig wrote:

 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6


The next step would be to introduce user defined annotations. I propose 
this:

//--------------

//declaring a user defined annotation type
 annotation
struct MyAnnotation {
     int x;
     char[] y;
     SubAnnotation sub;
}
struct SubAnnotation {
     int x;
}

//use the annotation on SomeType
 MyAnnotation(123, "456", SubAnnotation(789))
class SomeType {
}

//reading user defined annotations
void foo() {
     foreach (t; __traits(getAnnotations, SomeType) {
         //t is a value of the annotation type
         //SomeType is only annotated with MyAnnotation
         static assert(is(typeof(t) == MyAnnotation));
         //can read out the annotation values
         assert(t.y == "456");
     }
}
//--------------


Using  annotation on a type introduces the type name into the annotation 
namespace. This means the type can be used as annotation on other types.

The annotation declaration is parsed as if you'd define a compile time 
constant using the expression following the  , e.g. "const c = 
MyAnnotation(123, [...]);"
This means the   is actually just followed by an expression, that 
actually uses opCall() (in this case opCall is autogenerated by the 
compiler). The expression is evaluated using CTFE.

Note that compile time annotations (like  override,  property) still can 
collide with user defined types, but only if those types are marked by 
 annotation. (Actually, compile time annotations can be normal types 
declared in object.d.)

__traits(getAnnotations, SomeType) returns a tuple containing the values 
of all annotations applied to a type. In other words, the result of the 
CTFE execution of each annotation.


Any thoughts?

PS: I wouldn't use annotations for all attribute keywords (like 
override, final, pure, ...). Some keywords should be left as they are. 
Only seldom used and/or new keywords should be introduced as annotations 
(for example deprecated or __gshared [there's a type on the DIP page btw.]).

PPS: shoudl annotations follow the normal D attribute syntax? E.g. allow 
this:
 someannotation declaration;
 someannotation {
     declaration1;
     declaration2;
}
 someannotation:
     declaration1;
     declaration2;
Aug 02 2009
parent reply yigal chripun <yigal100 gmail.com> writes:
grauzone Wrote:


 Ary Borenszweig wrote:

 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6


 
 The next step would be to introduce user defined annotations. I propose 
 this:
 
 //--------------
 
 //declaring a user defined annotation type
  annotation
 struct MyAnnotation {
      int x;
      char[] y;
      SubAnnotation sub;
 }
 struct SubAnnotation {
      int x;
 }
 
 //use the annotation on SomeType
  MyAnnotation(123, "456", SubAnnotation(789))
 class SomeType {
 }
 
 //reading user defined annotations
 void foo() {
      foreach (t; __traits(getAnnotations, SomeType) {
          //t is a value of the annotation type
          //SomeType is only annotated with MyAnnotation
          static assert(is(typeof(t) == MyAnnotation));
          //can read out the annotation values
          assert(t.y == "456");
      }
 }
 //--------------
 
 
 Using  annotation on a type introduces the type name into the annotation 
 namespace. This means the type can be used as annotation on other types.
 
 The annotation declaration is parsed as if you'd define a compile time 
 constant using the expression following the  , e.g. "const c = 
 MyAnnotation(123, [...]);"
 This means the   is actually just followed by an expression, that 
 actually uses opCall() (in this case opCall is autogenerated by the 
 compiler). The expression is evaluated using CTFE.
 
 Note that compile time annotations (like  override,  property) still can 
 collide with user defined types, but only if those types are marked by 
  annotation. (Actually, compile time annotations can be normal types 
 declared in object.d.)
 
 __traits(getAnnotations, SomeType) returns a tuple containing the values 
 of all annotations applied to a type. In other words, the result of the 
 CTFE execution of each annotation.
 
 
 Any thoughts?
 
 PS: I wouldn't use annotations for all attribute keywords (like 
 override, final, pure, ...). Some keywords should be left as they are. 
 Only seldom used and/or new keywords should be introduced as annotations 
 (for example deprecated or __gshared [there's a type on the DIP page btw.]).
 
 PPS: shoudl annotations follow the normal D attribute syntax? E.g. allow 
 this:
  someannotation declaration;
  someannotation {
      declaration1;
      declaration2;
 }
  someannotation:
      declaration1;
      declaration2;


this is a good start but as already noted by others, you can't specify types
with structs. we also can't use type tuples cause of the auto flatten behavior. 

the type tuple issue needs to be fixed and perhaps we can introduce type
variables. something like:
type t = int; 

other thoughts on the subject:
the user should be able to specify the lifetime of the annotations,
compile-time vs. run-time.
Aug 03 2009
parent reply grauzone <none example.net> writes:
yigal chripun wrote:

 this is a good start but as already noted by others, you can't specify types
with structs. we also can't use type tuples cause of the auto flatten behavior. 


And why can't we use structs? Unless I've missed something, it wasn't 
explained in this thread.
Aug 03 2009
parent reply Kagamin <spam here.lot> writes:
grauzone Wrote:


 yigal chripun wrote:

 this is a good start but as already noted by others, you can't specify types
with structs. we also can't use type tuples cause of the auto flatten behavior. 


 
 And why can't we use structs? Unless I've missed something, it wasn't 
 explained in this thread.


inheritance?
Aug 03 2009
parent grauzone <none example.net> writes:
Kagamin wrote:

 grauzone Wrote:
 

 yigal chripun wrote:

 this is a good start but as already noted by others, you can't specify types
with structs. we also can't use type tuples cause of the auto flatten behavior. 


 And why can't we use structs? Unless I've missed something, it wasn't 
 explained in this thread.


 
 inheritance?


You want to inherit annotations? What for?
Aug 03 2009
prev sibling next sibling parent reply Don <nospam nospam.com> writes:
Ary Borenszweig wrote:

 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6


This looks like a solution in search of a problem. What's the problem 
being solved?
Aug 03 2009
next sibling parent reply grauzone <none example.net> writes:
Don wrote:

 Ary Borenszweig wrote:

 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6


 
 This looks like a solution in search of a problem. What's the problem 
 being solved?


Attaching additional data to types, that can't be specified otherwhere. 
This should help with metaprogramming-like stuff.

For example serialization. How do you specify that a field shouldn't be 
part of the serialized data? Java has an extra keyword attribute like 

we call annotation in this thread. How would you do this in D?
Aug 03 2009
next sibling parent reply Don <nospam nospam.com> writes:
grauzone wrote:

 Don wrote:

 Ary Borenszweig wrote:

 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6


 This looks like a solution in search of a problem. What's the problem 
 being solved?


 
 Attaching additional data to types, that can't be specified otherwhere. 
 This should help with metaprogramming-like stuff.
 
 For example serialization. How do you specify that a field shouldn't be 
 part of the serialized data? Java has an extra keyword attribute like

 we call annotation in this thread. How would you do this in D?


I agree that there doesn't seem to be a nice way at present. One 
possibility would be to establish a naming convention for transient 
fields -- a Ruby-style solution, I guess.

But are annotations actually an ideal solution for this problem?
Presumably, you'll have to specify that somewhere else anyway. I mean, 
during reading it will need to either be initialized separately after 
serialisation (like opPostBlit, perhaps?), or else remain uninitialized. 
Serialisation seems to be _extremely_ similar to construction. I'm not 
sure that annotations capture that.


intuition and hope is that we shouldn't need to adopt hacks from those 

ugly hack to me. Purely a subjective opinion, of course, but it seems 
really out of place in a C-family language.
Aug 03 2009
next sibling parent Kagamin <spam here.lot> writes:
Don Wrote:


 I agree that there doesn't seem to be a nice way at present. One 
 possibility would be to establish a naming convention for transient 
 fields -- a Ruby-style solution, I guess.
 
 But are annotations actually an ideal solution for this problem?
 Presumably, you'll have to specify that somewhere else anyway. I mean, 
 during reading it will need to either be initialized separately after 
 serialisation (like opPostBlit, perhaps?), or else remain uninitialized. 
 Serialisation seems to be _extremely_ similar to construction. I'm not 
 sure that annotations capture that.
 

 intuition and hope is that we shouldn't need to adopt hacks from those 

 ugly hack to me. Purely a subjective opinion, of course, but it seems 
 really out of place in a C-family language.


Here you considered functionality of only one attribute, XmlIgnoreAttribute.
XML serialization in .net framework uses 17 attributes. For example you can
serialize a field as an XML element or an XML attribute, how do you plan to
handle this?
Aug 03 2009
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 03 Aug 2009 09:26:21 -0400, Don <nospam nospam.com> wrote:


 grauzone wrote:

 Don wrote:

 Ary Borenszweig wrote:

 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6


 This looks like a solution in search of a problem. What's the problem  
 being solved?


  Attaching additional data to types, that can't be specified  
 otherwhere. This should help with metaprogramming-like stuff.
  For example serialization. How do you specify that a field shouldn't  
 be part of the serialized data? Java has an extra keyword attribute like

 what we call annotation in this thread. How would you do this in D?


 I agree that there doesn't seem to be a nice way at present. One  
 possibility would be to establish a naming convention for transient  
 fields -- a Ruby-style solution, I guess.

 But are annotations actually an ideal solution for this problem?
 Presumably, you'll have to specify that somewhere else anyway. I mean,  
 during reading it will need to either be initialized separately after  
 serialisation (like opPostBlit, perhaps?), or else remain uninitialized.  
 Serialisation seems to be _extremely_ similar to construction. I'm not  
 sure that annotations capture that.


Typically, items excluded from serialization are left uninitialized, or  
initialized via default initializers.  These types of items usually don't  
make sense to restore anyways, like file handles, or cached lookup data.



 intuition and hope is that we shouldn't need to adopt hacks from those  

 ugly hack to me. Purely a subjective opinion, of course, but it seems  
 really out of place in a C-family language.


Annotations have more usages than just how to serialize.  Some uses I've  


* hints to an IDE about a GUI component (what it does, what properties to  
allow setting via the visual builder)
* hints to the debugger about when to skip debugging certain functions (to  
avoid stepping into mundane crap such as property getters).
* hints to another program about which classes would be interesting when  
dynamically loading a library

On that last one, I wrote an editor that would create xml files indicating  
how to call constructors of certain types in an executable.  I tagged the  
types with attributes that described what they do, and how to display them  
in the editor (for example, is an integer a bitmask?  if so, display a set  
of checkboxes with these names).  Then when I would add classes to the  
executable, I did not have to update the editor.

Annotations are useful in many ways, but without full reflection  
capabilities, they are restricted to things that can read them via source  
code, and so they are no better than comments.

-Steve
Aug 03 2009
next sibling parent Don <nospam nospam.com> writes:
Steven Schveighoffer wrote:

 On Mon, 03 Aug 2009 09:26:21 -0400, Don <nospam nospam.com> wrote:
 

 grauzone wrote:

 Don wrote:

 Ary Borenszweig wrote:

 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6


 This looks like a solution in search of a problem. What's the 
 problem being solved?








[snip]


 Annotations are useful in many ways, but without full reflection 
 capabilities, they are restricted to things that can read them via 
 source code, and so they are no better than comments.


This is a very, very important observation, and I think it belongs in 
the DIP. It means that it probably doesn't make much sense to implement 
annotations without also having an intention to implement full-blown 
reflection.
Aug 03 2009
prev sibling parent Benji Smith <dlanguage benjismith.net> writes:
Steven Schveighoffer wrote:

 Annotations have more usages than just how to serialize.  Some uses I've 

 
 * hints to an IDE about a GUI component (what it does, what properties 
 to allow setting via the visual builder)
 * hints to the debugger about when to skip debugging certain functions 
 (to avoid stepping into mundane crap such as property getters).
 * hints to another program about which classes would be interesting when 
 dynamically loading a library


In Actionscript (and the Flex framework), one very handy use of 
annotations is to mark a public field as "bindable".

    class MyClass {

       [Bindable]
       public var MyField:int = 0;

    }

In this example, whenever the "MyField" value is updated, a 
property-change event will be send to all listeners. The XML-based Flex 
framework uses those annotations to create (unidirectional or 
bidirectional) bindings between variables.

     <Window>
         <HSlider id="mySlider"/>
         <Image
            source="..."
            width="{mySlider.value}"
            height="{mySlider.value}"
         />
     </Window>

This creates a window with two controls, a horizontal numeric slider and 
an image. Whenever the user drags the slider control, the width and 
height of the image automatically update themselves.

The reason this works is that the "value" field of the "HSlider"
object is marked with the "Bindable" annotation. The compiler silently 
converts the field into a property getter/setter pair, and the setter 
sends out property-change events whenever called.

(Good thing Actionscript properties exist, with a syntax identical to 
normal fields, or else the automatic data binding wouldn't work!)

The cool thing that makes this work is that the compiler can perform 
code transformation based on the existence of various annotations.

--benji
Aug 03 2009
prev sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Don escribió:

 grauzone wrote:

 Don wrote:

 Ary Borenszweig wrote:

 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6


 This looks like a solution in search of a problem. What's the problem 
 being solved?


 Attaching additional data to types, that can't be specified 
 otherwhere. This should help with metaprogramming-like stuff.

 For example serialization. How do you specify that a field shouldn't 
 be part of the serialized data? Java has an extra keyword attribute like

 what we call annotation in this thread. How would you do this in D?


 
 I agree that there doesn't seem to be a nice way at present. One 
 possibility would be to establish a naming convention for transient 
 fields -- a Ruby-style solution, I guess.
 
 But are annotations actually an ideal solution for this problem?
 Presumably, you'll have to specify that somewhere else anyway. I mean, 
 during reading it will need to either be initialized separately after 
 serialisation (like opPostBlit, perhaps?), or else remain uninitialized. 
 Serialisation seems to be _extremely_ similar to construction. I'm not 
 sure that annotations capture that.
 

 intuition and hope is that we shouldn't need to adopt hacks from those 

 ugly hack to me. Purely a subjective opinion, of course, but it seems 
 really out of place in a C-family language.


Attributes has many, many other uses. Appart from serialization, you 
could specify how a field is stored in a database. How a method maps to 
an http request (post, get, which parameters to bind to the request, 
etc.). Whether a method should do security checks before executing. 
Whether a method should be run as a test, and what's the expected 
exception to be thrown. [insert your usage here]
Aug 03 2009
next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Ary Borenszweig, el  3 de agosto a las 11:14 me escribiste:


subjective opinion, of course, but it seems really out of place in a C-family 
language.


 
 Attributes has many, many other uses. Appart from serialization, you could 
 specify how a field is stored in a database. How a method maps to an http 
 request (post, get, which parameters to bind to the request, etc.). Whether a 
 method should do security checks before executing. Whether a method should be 
 run as a test, and what's the expected exception to be thrown. [insert your 
 usage here]


It's easy to support some sort of primitive-explicit AOP[1] too. It's very
used in Python. For example I've implemented the synchronized "attribute"
in Python using decorators (annotations).

[1] http://en.wikipedia.org/wiki/Aspect-oriented_programming

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
I love las minifaldas on Esmeralda
And the sexy porteños trying to pick up the Argenteenagers.
How nice, the Argenteenagers
Tomando sol in the primavera de Buenos Aires...
Aug 03 2009
prev sibling parent reply Don <nospam nospam.com> writes:
Ary Borenszweig wrote:

 Don escribió:

 grauzone wrote:

 Don wrote:

 Ary Borenszweig wrote:

 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6


 This looks like a solution in search of a problem. What's the 
 problem being solved?


 Attaching additional data to types, that can't be specified 
 otherwhere. This should help with metaprogramming-like stuff.

 For example serialization. How do you specify that a field shouldn't 
 be part of the serialized data? Java has an extra keyword attribute like

 what we call annotation in this thread. How would you do this in D?


 I agree that there doesn't seem to be a nice way at present. One 
 possibility would be to establish a naming convention for transient 
 fields -- a Ruby-style solution, I guess.

 But are annotations actually an ideal solution for this problem?
 Presumably, you'll have to specify that somewhere else anyway. I mean, 
 during reading it will need to either be initialized separately after 
 serialisation (like opPostBlit, perhaps?), or else remain 
 uninitialized. Serialisation seems to be _extremely_ similar to 
 construction. I'm not sure that annotations capture that.


 intuition and hope is that we shouldn't need to adopt hacks from those 

 ugly hack to me. Purely a subjective opinion, of course, but it seems 
 really out of place in a C-family language.


 
 Attributes has many, many other uses. Appart from serialization, you 
 could specify how a field is stored in a database. How a method maps to 
 an http request (post, get, which parameters to bind to the request, 
 etc.). Whether a method should do security checks before executing. 
 Whether a method should be run as a test, and what's the expected 
 exception to be thrown. [insert your usage here]


Great, you've answered my question. That should be in the DIP, instead 
of the vague stuff that's in there now -- the existing DIP is about 
replacing keywords, which is very unconvincing. (It doesn't work, 
actually -- the name mangling is important for most of the keywords 
mentioned).
Aug 03 2009
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Don wrote:

 Ary Borenszweig wrote:

 Don escribió:

 grauzone wrote:

 Don wrote:

 Ary Borenszweig wrote:

 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6


 This looks like a solution in search of a problem. What's the 
 problem being solved?


 Attaching additional data to types, that can't be specified 
 otherwhere. This should help with metaprogramming-like stuff.

 For example serialization. How do you specify that a field shouldn't 
 be part of the serialized data? Java has an extra keyword attribute 
 like

 what we call annotation in this thread. How would you do this in D?


 I agree that there doesn't seem to be a nice way at present. One 
 possibility would be to establish a naming convention for transient 
 fields -- a Ruby-style solution, I guess.

 But are annotations actually an ideal solution for this problem?
 Presumably, you'll have to specify that somewhere else anyway. I 
 mean, during reading it will need to either be initialized separately 
 after serialisation (like opPostBlit, perhaps?), or else remain 
 uninitialized. Serialisation seems to be _extremely_ similar to 
 construction. I'm not sure that annotations capture that.


 intuition and hope is that we shouldn't need to adopt hacks from 

 like an ugly hack to me. Purely a subjective opinion, of course, but 
 it seems really out of place in a C-family language.


 Attributes has many, many other uses. Appart from serialization, you 
 could specify how a field is stored in a database. How a method maps 
 to an http request (post, get, which parameters to bind to the 
 request, etc.). Whether a method should do security checks before 
 executing. Whether a method should be run as a test, and what's the 
 expected exception to be thrown. [insert your usage here]


 
 Great, you've answered my question. That should be in the DIP, instead 
 of the vague stuff that's in there now -- the existing DIP is about 
 replacing keywords, which is very unconvincing. (It doesn't work, 
 actually -- the name mangling is important for most of the keywords 
 mentioned).


But the DIP I wrote isn't about general-purpose annotations. It's just 
the first step. Are "pure" and "nothrow" part of the mangling? Or which 
are? I thought not. Can you overload a pure and a not-pure function with 
the same parameter count and types?

Anyway, I'll write some more about attributes in the abstract or rationale.
Aug 03 2009
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 03 Aug 2009 11:42:33 -0400, Ary Borenszweig <ary esperanto.org.ar>  
wrote:


 Don wrote:

 Ary Borenszweig wrote:

 Don escribió:

 grauzone wrote:

 Don wrote:

 Ary Borenszweig wrote:

 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6


 This looks like a solution in search of a problem. What's the  
 problem being solved?


 Attaching additional data to types, that can't be specified  
 otherwhere. This should help with metaprogramming-like stuff.

 For example serialization. How do you specify that a field shouldn't  
 be part of the serialized data? Java has an extra keyword attribute  
 like

 what we call annotation in this thread. How would you do this in D?


 I agree that there doesn't seem to be a nice way at present. One  
 possibility would be to establish a naming convention for transient  
 fields -- a Ruby-style solution, I guess.

 But are annotations actually an ideal solution for this problem?
 Presumably, you'll have to specify that somewhere else anyway. I  
 mean, during reading it will need to either be initialized separately  
 after serialisation (like opPostBlit, perhaps?), or else remain  
 uninitialized. Serialisation seems to be _extremely_ similar to  
 construction. I'm not sure that annotations capture that.


 intuition and hope is that we shouldn't need to adopt hacks from  

 like an ugly hack to me. Purely a subjective opinion, of course, but  
 it seems really out of place in a C-family language.


 Attributes has many, many other uses. Appart from serialization, you  
 could specify how a field is stored in a database. How a method maps  
 to an http request (post, get, which parameters to bind to the  
 request, etc.). Whether a method should do security checks before  
 executing. Whether a method should be run as a test, and what's the  
 expected exception to be thrown. [insert your usage here]


  Great, you've answered my question. That should be in the DIP, instead  
 of the vague stuff that's in there now -- the existing DIP is about  
 replacing keywords, which is very unconvincing. (It doesn't work,  
 actually -- the name mangling is important for most of the keywords  
 mentioned).


 But the DIP I wrote isn't about general-purpose annotations. It's just  
 the first step. Are "pure" and "nothrow" part of the mangling? Or which  
 are? I thought not. Can you overload a pure and a not-pure function with  
 the same parameter count and types?


Yes, they have to be.  There are reasons besides overloading for including  
other attributes in the naming.

For example, if a function is pure, then becomes unpure, you don't  
existing code that is expecting a pure function to link against it.

In other words, the linker is dumb.  It only knows how to match symbols,  
so you have to embed into the symbols the important pieces of the  
interface that you want the linker to consider important.

To answer Don's point, there is nothing saying that the compiler can't  
read attributes and change its behavior.  Of course, those would have to  
be builtin attributes.

My opinion on removing existing keywords is -- don't.  There's little to  
no gain.  Let that ship sail, and concentrate on future keyword proposals.

-Steve
Aug 03 2009
next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Mon, 03 Aug 2009 19:53:21 +0400, Steven Schveighoffer  =

<schveiguy yahoo.com> wrote:


 On Mon, 03 Aug 2009 11:42:33 -0400, Ary Borenszweig  =



 <ary esperanto.org.ar> wrote:


 Don wrote:

 Ary Borenszweig wrote:

 Don escribi=C3=B3:

 grauzone wrote:

 Don wrote:

 Ary Borenszweig wrote:

 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6


 This looks like a solution in search of a problem. What's the  =















 problem being solved?


 Attaching additional data to types, that can't be specified  =













 otherwhere. This should help with metaprogramming-like stuff.

 For example serialization. How do you specify that a field  =













 shouldn't be part of the serialized data? Java has an extra keywo=












rd  =


 attribute like













es  =


 what we call annotation in this thread. How would you do this in =












D?

 I agree that there doesn't seem to be a nice way at present. One  =











 possibility would be to establish a naming convention for transien=










t  =


 fields -- a Ruby-style solution, I guess.

 But are annotations actually an ideal solution for this problem?
 Presumably, you'll have to specify that somewhere else anyway. I  =











 mean, during reading it will need to either be initialized  =











 separately after serialisation (like opPostBlit, perhaps?), or els=










e  =


 remain uninitialized. Serialisation seems to be _extremely_ simila=










r  =


 to construction. I'm not sure that annotations capture that.













 intuition and hope is that we shouldn't need to adopt hacks from  =






















  =


 like an ugly hack to me. Purely a subjective opinion, of course, b=










ut  =


 it seems really out of place in a C-family language.


 Attributes has many, many other uses. Appart from serialization, yo=








u  =


 could specify how a field is stored in a database. How a method map=








s  =


 to an http request (post, get, which parameters to bind to the  =









 request, etc.). Whether a method should do security checks before  =









 executing. Whether a method should be run as a test, and what's the=








  =


 expected exception to be thrown. [insert your usage here]


  Great, you've answered my question. That should be in the DIP,  =







 instead of the vague stuff that's in there now -- the existing DIP i=






s  =


 about replacing keywords, which is very unconvincing. (It doesn't  =







 work, actually -- the name mangling is important for most of the  =







 keywords mentioned).


 But the DIP I wrote isn't about general-purpose annotations. It's jus=




t  =


 the first step. Are "pure" and "nothrow" part of the mangling? Or whi=




ch  =


 are? I thought not. Can you overload a pure and a not-pure function  =





 with the same parameter count and types?


 Yes, they have to be.  There are reasons besides overloading for  =



 including other attributes in the naming.

 For example, if a function is pure, then becomes unpure, you don't  =



 existing code that is expecting a pure function to link against it.

 In other words, the linker is dumb.  It only knows how to match symbol=


s,  =


 so you have to embed into the symbols the important pieces of the  =



 interface that you want the linker to consider important.

 To answer Don's point, there is nothing saying that the compiler can't=


  =


 read attributes and change its behavior.  Of course, those would have =


to  =


 be builtin attributes.

 My opinion on removing existing keywords is -- don't.  There's little =


to  =


 no gain.  Let that ship sail, and concentrate on future keyword  =



 proposals.

 -Steve


Compiler could embed some kind of a hash from attributes in a mangled na=
me.
Aug 03 2009
prev sibling next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Steven Schveighoffer, el  3 de agosto a las 11:53 me escribiste:

But the DIP I wrote isn't about general-purpose annotations. It's just the 
first step. Are "pure" and "nothrow" part of the mangling? Or which are? I 
thought not. Can you overload a pure and a not-pure function with the same 
parameter count and types?


 
 Yes, they have to be.  There are reasons besides overloading for including
other 
 attributes in the naming.
 
 For example, if a function is pure, then becomes unpure, you don't existing
code 
 that is expecting a pure function to link against it.
 
 In other words, the linker is dumb.  It only knows how to match symbols, so
you 
 have to embed into the symbols the important pieces of the interface that you 
 want the linker to consider important.
 
 To answer Don's point, there is nothing saying that the compiler can't read 
 attributes and change its behavior.  Of course, those would have to be builtin 
 attributes.
 
 My opinion on removing existing keywords is -- don't.  There's little to no 
 gain.  Let that ship sail, and concentrate on future keyword proposals.


I think old keywords can be maintained for backward compatibility but
deprecated (allowing using both "naked" keywords or "annotations"),
favoring the usage of annoatations where sensible. In a far far future,
the old keywords can be removed if annotations prove to be a success.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Novocaine for the soul
you better give me something
to fill the hole
before I sputter out
Aug 03 2009
prev sibling parent reply Don <nospam nospam.com> writes:
Steven Schveighoffer wrote:

 On Mon, 03 Aug 2009 11:42:33 -0400, Ary Borenszweig 
 <ary esperanto.org.ar> wrote:
 

 Don wrote:

 Ary Borenszweig wrote:

 Don escribió:

 grauzone wrote:

 Don wrote:

 Ary Borenszweig wrote:

 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6


 This looks like a solution in search of a problem. What's the 
 problem being solved?


 Attaching additional data to types, that can't be specified 
 otherwhere. This should help with metaprogramming-like stuff.

 For example serialization. How do you specify that a field 
 shouldn't be part of the serialized data? Java has an extra 
 keyword attribute like

 uses what we call annotation in this thread. How would you do this 
 in D?


 I agree that there doesn't seem to be a nice way at present. One 
 possibility would be to establish a naming convention for transient 
 fields -- a Ruby-style solution, I guess.

 But are annotations actually an ideal solution for this problem?
 Presumably, you'll have to specify that somewhere else anyway. I 
 mean, during reading it will need to either be initialized 
 separately after serialisation (like opPostBlit, perhaps?), or else 
 remain uninitialized. Serialisation seems to be _extremely_ similar 
 to construction. I'm not sure that annotations capture that.


 intuition and hope is that we shouldn't need to adopt hacks from 

 like an ugly hack to me. Purely a subjective opinion, of course, 
 but it seems really out of place in a C-family language.


 Attributes has many, many other uses. Appart from serialization, you 
 could specify how a field is stored in a database. How a method maps 
 to an http request (post, get, which parameters to bind to the 
 request, etc.). Whether a method should do security checks before 
 executing. Whether a method should be run as a test, and what's the 
 expected exception to be thrown. [insert your usage here]


  Great, you've answered my question. That should be in the DIP, 
 instead of the vague stuff that's in there now -- the existing DIP is 
 about replacing keywords, which is very unconvincing. (It doesn't 
 work, actually -- the name mangling is important for most of the 
 keywords mentioned).


 But the DIP I wrote isn't about general-purpose annotations. It's just 
 the first step. Are "pure" and "nothrow" part of the mangling? Or 
 which are? I thought not. Can you overload a pure and a not-pure 
 function with the same parameter count and types?


 
 Yes, they have to be.  There are reasons besides overloading for 
 including other attributes in the naming.
 
 For example, if a function is pure, then becomes unpure, you don't 
 existing code that is expecting a pure function to link against it.
 
 In other words, the linker is dumb.  It only knows how to match symbols, 
 so you have to embed into the symbols the important pieces of the 
 interface that you want the linker to consider important.




delegate declarations?

void foo( int delegate(int) pure dg) {
   ...
}
What would this look like with annotations?

(The underlying question is, how do annotations interact with the type 
system?)


 To answer Don's point, there is nothing saying that the compiler can't 
 read attributes and change its behavior.  Of course, those would have to 
 be builtin attributes.


Yes, but then they're just keywords, with an   in front. You'd just be 
kidding yourself if you think you've reduced the keyword count.


 My opinion on removing existing keywords is -- don't.  There's little to 
 no gain.  Let that ship sail, and concentrate on future keyword proposals.
 
 -Steve
Aug 04 2009
next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Don wrote:

 ...
 

 delegate declarations?
 
 void foo( int delegate(int) pure dg) {
   ...
 }
 What would this look like with annotations?



define them inline; they have a special declaration syntax that can't be
used in an expression.



namespace Blech
{
    [Pure]
    public delegate int Moo(int);

    public class Urk
    {
        public static void foo(Moo dg) {
            ...
        }
    }
}


 (The underlying question is, how do annotations interact with the type
 system?)


I don't think they form part of the type; they're just sort of attached
to that particular declaration.


 To answer Don's point, there is nothing saying that the compiler can't
 read attributes and change its behavior.  Of course, those would have
 to be builtin attributes.


 
 Yes, but then they're just keywords, with an   in front. You'd just be
 kidding yourself if you think you've reduced the keyword count.


I suspect the reasoning goes like this:

* I want attributes.  Walter doesn't see the use.
* Walter complains about adding keywords.
* I can make keywords look like attributes, and then I get attributes!

:P


 My opinion on removing existing keywords is -- don't.  There's little
 to no gain.  Let that ship sail, and concentrate on future keyword
 proposals.

 -Steve
Aug 04 2009
next sibling parent reply grauzone <none example.net> writes:
Daniel Keep wrote:

 Yes, but then they're just keywords, with an   in front. You'd just be
 kidding yourself if you think you've reduced the keyword count.


 
 I suspect the reasoning goes like this:
 
 * I want attributes.  Walter doesn't see the use.
 * Walter complains about adding keywords.
 * I can make keywords look like attributes, and then I get attributes!
 
 :P




keywords/annotations are in a different namespace and 2. even compile 
time "keyword" annotations can be handled as normal identifiers. The 
second point means introducing a new keyword is like declaring a new 
identifier in object.d.

But it would also allow users shadowing annotation "keywords" by 
defining their own annotations, which might be a problem or not.
Aug 04 2009
parent yigal chripun <yigal100 gmail.com> writes:
grauzone Wrote:


 Daniel Keep wrote:

 Yes, but then they're just keywords, with an   in front. You'd just be
 kidding yourself if you think you've reduced the keyword count.


 
 I suspect the reasoning goes like this:
 
 * I want attributes.  Walter doesn't see the use.
 * Walter complains about adding keywords.
 * I can make keywords look like attributes, and then I get attributes!
 
 :P


 
 

 keywords/annotations are in a different namespace and 2. even compile 
 time "keyword" annotations can be handled as normal identifiers. The 
 second point means introducing a new keyword is like declaring a new 
 identifier in object.d.
 
 But it would also allow users shadowing annotation "keywords" by 
 defining their own annotations, which might be a problem or not.



int  if = 3; // this is a variable called "if"
Aug 04 2009
prev sibling parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Tue, 04 Aug 2009 17:22:50 +1000, Daniel Keep wrote:


 Don wrote:

 ...
 

 delegate declarations?
 
 void foo( int delegate(int) pure dg) {
   ...
 }
 What would this look like with annotations?


 

 define them inline; they have a special declaration syntax that can't be
 used in an expression.




List<int> ls;
ls.Sort((x, y) => y - x);

or

ls.Sort((x, y) => { int a; a = y; a -= x; return a; });
Aug 04 2009
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Sergey Gromov wrote:

 Tue, 04 Aug 2009 17:22:50 +1000, Daniel Keep wrote:
 

 Don wrote:

 ...


 delegate declarations?

 void foo( int delegate(int) pure dg) {
   ...
 }
 What would this look like with annotations?



 define them inline; they have a special declaration syntax that can't be
 used in an expression.


 

 
 List<int> ls;
 ls.Sort((x, y) => y - x);
 
 or
 
 ls.Sort((x, y) => { int a; a = y; a -= x; return a; });


That's not a delegate type, that's a delegate literal.
Aug 04 2009
parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Tue, 04 Aug 2009 22:46:22 +1000, Daniel Keep wrote:


 Sergey Gromov wrote:

 Tue, 04 Aug 2009 17:22:50 +1000, Daniel Keep wrote:
 

 Don wrote:

 ...


 delegate declarations?

 void foo( int delegate(int) pure dg) {
   ...
 }
 What would this look like with annotations?



 define them inline; they have a special declaration syntax that can't be
 used in an expression.


 

 
 List<int> ls;
 ls.Sort((x, y) => y - x);
 
 or
 
 ls.Sort((x, y) => { int a; a = y; a -= x; return a; });


 
 That's not a delegate type, that's a delegate literal.



inline".  Delegate literal *is* an inline definition of a delegate.

inside a function which is definitely true and is very annoying.
Aug 04 2009
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Sergey Gromov wrote:

 Tue, 04 Aug 2009 22:46:22 +1000, Daniel Keep wrote:
 

 Sergey Gromov wrote:

 Tue, 04 Aug 2009 17:22:50 +1000, Daniel Keep wrote:


 Don wrote:

 ...


 delegate declarations?

 void foo( int delegate(int) pure dg) {
   ...
 }
 What would this look like with annotations?



 define them inline; they have a special declaration syntax that can't be
 used in an expression.




 List<int> ls;
 ls.Sort((x, y) => y - x);

 or

 ls.Sort((x, y) => { int a; a = y; a -= x; return a; });


 That's not a delegate type, that's a delegate literal.


 

 inline".  Delegate literal *is* an inline definition of a delegate.

 inside a function which is definitely true and is very annoying.


Have you seen the Func delegates? They are exactly for that.

The above example would be:

void foo(Func<int, int> dg) { ... }
Aug 04 2009
parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Tue, 04 Aug 2009 11:58:27 -0300, Ary Borenszweig wrote:


 Sergey Gromov wrote:

 Tue, 04 Aug 2009 22:46:22 +1000, Daniel Keep wrote:
 

 Sergey Gromov wrote:

 Tue, 04 Aug 2009 17:22:50 +1000, Daniel Keep wrote:


 Don wrote:

 ...


 delegate declarations?

 void foo( int delegate(int) pure dg) {
   ...
 }
 What would this look like with annotations?



 define them inline; they have a special declaration syntax that can't be
 used in an expression.




 List<int> ls;
 ls.Sort((x, y) => y - x);

 or

 ls.Sort((x, y) => { int a; a = y; a -= x; return a; });


 That's not a delegate type, that's a delegate literal.


 

 inline".  Delegate literal *is* an inline definition of a delegate.

 inside a function which is definitely true and is very annoying.


 
 Have you seen the Func delegates? They are exactly for that.
 
 The above example would be:
 
 void foo(Func<int, int> dg) { ... }


Func defines a delegate with one argument and a non-void return.  There
are lots of others like Action, Predicate, Comparator etc. which you
must either remember or look up every time you need a specific delegate
signature.
Aug 04 2009
parent Ary Borenszweig <ary esperanto.org.ar> writes:
Sergey Gromov wrote:

 Tue, 04 Aug 2009 11:58:27 -0300, Ary Borenszweig wrote:
 

 Sergey Gromov wrote:

 Tue, 04 Aug 2009 22:46:22 +1000, Daniel Keep wrote:


 Sergey Gromov wrote:

 Tue, 04 Aug 2009 17:22:50 +1000, Daniel Keep wrote:


 Don wrote:

 ...


 delegate declarations?

 void foo( int delegate(int) pure dg) {
   ...
 }
 What would this look like with annotations?



 define them inline; they have a special declaration syntax that can't be
 used in an expression.




 List<int> ls;
 ls.Sort((x, y) => y - x);

 or

 ls.Sort((x, y) => { int a; a = y; a -= x; return a; });


 That's not a delegate type, that's a delegate literal.



 inline".  Delegate literal *is* an inline definition of a delegate.

 inside a function which is definitely true and is very annoying.


 Have you seen the Func delegates? They are exactly for that.

 The above example would be:

 void foo(Func<int, int> dg) { ... }


 
 Func defines a delegate with one argument and a non-void return.  There
 are lots of others like Action, Predicate, Comparator etc. which you
 must either remember or look up every time you need a specific delegate
 signature.


Ah, I didn't know you can't do something like Func<void, int>. So there 
could just be two things to remember: Func and Action.

Also you have Func<T1, T2, TResult>, Func<T1, T2, T3, TResult>, so it's 
not just one argument.

I just tried casting one delegate type to another one with the same 
signature and it doesn't work. So you are right, you need to remember 
Predicate, Comparator, etc. :-(
Aug 04 2009
prev sibling next sibling parent reply Kagamin <spam here.lot> writes:
Don Wrote:


 To answer Don's point, there is nothing saying that the compiler can't 
 read attributes and change its behavior.  Of course, those would have to 
 be builtin attributes.


 
 Yes, but then they're just keywords, with an   in front. You'd just be 
 kidding yourself if you think you've reduced the keyword count.


The problem with keywords is they're global. Why do you think there is module
std.string, but there isn't core.stdc.wchar? It's because string is not a
keyword, while wchar is. And annotations are also identifiers (though
predefined, like Object) rather than keywords.
Aug 04 2009
parent Don <nospam nospam.com> writes:
Kagamin wrote:

 Don Wrote:
 

 To answer Don's point, there is nothing saying that the compiler can't 
 read attributes and change its behavior.  Of course, those would have to 
 be builtin attributes.


 Yes, but then they're just keywords, with an   in front. You'd just be 
 kidding yourself if you think you've reduced the keyword count.


 
 The problem with keywords is they're global. Why do you think there is module
std.string, but there isn't core.stdc.wchar? It's because string is not a
keyword, while wchar is. And annotations are also identifiers (though
predefined, like Object) rather than keywords.


No, that's only one of the problems with keywords. Prefixing all new 
keywords with __ solves the same problem, and it's no more ugly than 
prefixing with  . But it doesn't solve the other keyword problems.
Aug 04 2009
prev sibling next sibling parent Ary Borenszweig <ary esperanto.org.ar> writes:
Don escribió:

 Steven Schveighoffer wrote:

 On Mon, 03 Aug 2009 11:42:33 -0400, Ary Borenszweig 
 <ary esperanto.org.ar> wrote:


 Don wrote:

 Ary Borenszweig wrote:

 Don escribió:

 grauzone wrote:

 Don wrote:

 Ary Borenszweig wrote:

 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6


 This looks like a solution in search of a problem. What's the 
 problem being solved?


 Attaching additional data to types, that can't be specified 
 otherwhere. This should help with metaprogramming-like stuff.

 For example serialization. How do you specify that a field 
 shouldn't be part of the serialized data? Java has an extra 
 keyword attribute like

 uses what we call annotation in this thread. How would you do 
 this in D?


 I agree that there doesn't seem to be a nice way at present. One 
 possibility would be to establish a naming convention for 
 transient fields -- a Ruby-style solution, I guess.

 But are annotations actually an ideal solution for this problem?
 Presumably, you'll have to specify that somewhere else anyway. I 
 mean, during reading it will need to either be initialized 
 separately after serialisation (like opPostBlit, perhaps?), or 
 else remain uninitialized. Serialisation seems to be _extremely_ 
 similar to construction. I'm not sure that annotations capture that.


 intuition and hope is that we shouldn't need to adopt hacks from 

 like an ugly hack to me. Purely a subjective opinion, of course, 
 but it seems really out of place in a C-family language.


 Attributes has many, many other uses. Appart from serialization, 
 you could specify how a field is stored in a database. How a method 
 maps to an http request (post, get, which parameters to bind to the 
 request, etc.). Whether a method should do security checks before 
 executing. Whether a method should be run as a test, and what's the 
 expected exception to be thrown. [insert your usage here]


  Great, you've answered my question. That should be in the DIP, 
 instead of the vague stuff that's in there now -- the existing DIP 
 is about replacing keywords, which is very unconvincing. (It doesn't 
 work, actually -- the name mangling is important for most of the 
 keywords mentioned).


 But the DIP I wrote isn't about general-purpose annotations. It's 
 just the first step. Are "pure" and "nothrow" part of the mangling? 
 Or which are? I thought not. Can you overload a pure and a not-pure 
 function with the same parameter count and types?


 Yes, they have to be.  There are reasons besides overloading for 
 including other attributes in the naming.

 For example, if a function is pure, then becomes unpure, you don't 
 existing code that is expecting a pure function to link against it.

 In other words, the linker is dumb.  It only knows how to match 
 symbols, so you have to embed into the symbols the important pieces of 
 the interface that you want the linker to consider important.


 
 

 delegate declarations?
 
 void foo( int delegate(int) pure dg) {
   ...
 }
 What would this look like with annotations?
 
 (The underlying question is, how do annotations interact with the type 
 system?)



things: declarations, statements, function arguments. I don't know if 
expressions.

So you could do:

void foo( pure int delegate(int) dg) {
}

but that'll mark as pure the argument dg, not the type of dg. That 
doesn't mean there shouldn't be a way to annotate types.
Aug 04 2009
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 04 Aug 2009 03:03:12 -0400, Don <nospam nospam.com> wrote:



 delegate declarations?

 void foo( int delegate(int) pure dg) {
    ...
 }
 What would this look like with annotations?

 (The underlying question is, how do annotations interact with the type  
 system?)


I'm not familiar with Java annotations, it's been a while since I used  
Java.


are attached to a declaration (e.g. a class, member, function parameter).   
So basically, an attribute can modify how the compiler treats something,  
but it doesn't allow you to define new types with it.  I suppose you could  
use it that way, but I think it would be better to just use it as hints  
and information, not an integral part of the type system.

When you have runtime reflection, you can query for attributes on almost  
anything, but they are usually descriptors, and don't affect type  
matching.  The only places I've used it are as hints to other things  
reading my compiled objects.  For example, SerializableAttribute is used  
by serializers to know what to serialize and what not to serialize.

If pure weren't part of the function signature, but simply a way to  
compile a function, then it would be fine as an annotation.

A good usage for annotation, for example, would be scope, since it simply  
indicates where the compiler should put things, and doesn't affect types  
or signatures.


 To answer Don's point, there is nothing saying that the compiler can't  
 read attributes and change its behavior.  Of course, those would have  
 to be builtin attributes.


 Yes, but then they're just keywords, with an   in front. You'd just be  
 kidding yourself if you think you've reduced the keyword count.


keywords are global, that was one of Walter's main points against adding a  
keyword for properties.  Since annotations necessarily have a different  
syntax than normal symbols, you don't have to worry about avoiding those  
words.  Others have also said that adding a builtin annotation would be  
easier because it doesn't affect the parser.

For the record, I'm not really keen on using annotations for *everything*  
as some people have suggested.  They have good uses, but I don't think  
it's worth adding them until we can have full reflection capabilities so  
we can get at elements of code and therefore get the annotations  
associated with it.  I see much more usefulness for annotations as  
reflection hints than as a replacement for keywords.

-Steve
Aug 04 2009
parent reply grauzone <none example.net> writes:
Steven Schveighoffer wrote:

 For the record, I'm not really keen on using annotations for 
 *everything* as some people have suggested.  They have good uses, but I 


Me neither, but I think they'd be a worthy feature. Of course, there are 
far more pressing issues, but if Walter has time to introduce 
const/immutable/pure, then why not annotations?


 don't think it's worth adding them until we can have full reflection 
 capabilities so we can get at elements of code and therefore get the 
 annotations associated with it.  I see much more usefulness for 
 annotations as reflection hints than as a replacement for keywords.


But we already have full reflection. It's called __traits. You can build 
a serialization library or "proper" (user friendly?) reflection on top 
of it.
Aug 04 2009
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 04 Aug 2009 09:45:51 -0400, grauzone <none example.net> wrote:


 Steven Schveighoffer wrote:

 don't think it's worth adding them until we can have full reflection  
 capabilities so we can get at elements of code and therefore get the  
 annotations associated with it.  I see much more usefulness for  
 annotations as reflection hints than as a replacement for keywords.


 But we already have full reflection. It's called __traits. You can build  
 a serialization library or "proper" (user friendly?) reflection on top  
 of it.


I think you are the 1 millionth person to say it, and yet we still do not  
have a "user friendly" reflection system.  Why is that?  You'd think that  
if it could be done, somebody would have done it by now.

-Steve
Aug 04 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:

 On Tue, 04 Aug 2009 09:45:51 -0400, grauzone <none example.net> wrote:
 

 Steven Schveighoffer wrote:

 don't think it's worth adding them until we can have full reflection 
 capabilities so we can get at elements of code and therefore get the 
 annotations associated with it.  I see much more usefulness for 
 annotations as reflection hints than as a replacement for keywords.


 But we already have full reflection. It's called __traits. You can 
 build a serialization library or "proper" (user friendly?) reflection 
 on top of it.


 
 I think you are the 1 millionth person to say it, and yet we still do 
 not have a "user friendly" reflection system.  Why is that?  You'd think 
 that if it could be done, somebody would have done it by now.


The reality is there's quite few of us. D is not in the stage where if 
something could be done, somebody somewhere has done it or is working on it.

For example, I myself didn't know about __traits(allMembers) until it 
was mentioned in this group. That's why I'd defined defineEnum, which 
now is a relic replaced by the appropriate mechanism, contributed to by 
Shin Fujishiro.

I know exactly how to go about a reflection system, but I simply haven't 
gotten around to it. Here's an initial shot: starting with std.variant, 
implement a function "call":

class A { int foo() { return 42; } }
...
auto v = Variant(new A);
writeln(*v.call("foo").peek!int());

That should print 42. This is eminently doable with what we have now, 
and could then be extended to multiple arguments etc. with the 
appropriate amount of sweat.

The way to implement this would be to use __traits(allMembers) in the 
templated constructor to store a hash that maps strings to delegates. 
The delegates take no argument and return Variant. During construction 
you can figure which members can be invoked with no arguments by using 
e.g. is(typeof(...)) and initialize the hash appropriately. In the 
call() function, you look up the string and fire the delegate.


Andrei
Aug 04 2009
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 04 Aug 2009 12:23:41 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


 Steven Schveighoffer wrote:

 On Tue, 04 Aug 2009 09:45:51 -0400, grauzone <none example.net> wrote:


 Steven Schveighoffer wrote:

 don't think it's worth adding them until we can have full reflection  
 capabilities so we can get at elements of code and therefore get the  
 annotations associated with it.  I see much more usefulness for  
 annotations as reflection hints than as a replacement for keywords.


 But we already have full reflection. It's called __traits. You can  
 build a serialization library or "proper" (user friendly?) reflection  
 on top of it.


  I think you are the 1 millionth person to say it, and yet we still do  
 not have a "user friendly" reflection system.  Why is that?  You'd  
 think that if it could be done, somebody would have done it by now.


 The reality is there's quite few of us. D is not in the stage where if  
 something could be done, somebody somewhere has done it or is working on  
 it.


That's understandable, nobody can expect a language as young as D to have  
everything.

But in reality, I think the *theory* that everything is there to build a  
reflection system is only proven when it actually happens.  I'm sure when  
the enterprising person or persons go to develop it, they will find pieces  
missing from the static reflection system.

So my point is that adding annotations before reflection works and is  
implemented makes little sense to me, because the usage of them will be  
crippled by the fact that reflection isn't complete.

What I'd like to see is something like this possible:

void foo (int timeout, string bar, float f = 4.0);

void foo(int timeout);

call!(foo)("timeout=5,bar=\"hello\"");

Taking into account the default value of f, what the parameters are named,  


-Steve
Aug 04 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:

 On Tue, 04 Aug 2009 12:23:41 -0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 

 Steven Schveighoffer wrote:

 On Tue, 04 Aug 2009 09:45:51 -0400, grauzone <none example.net> wrote:


 Steven Schveighoffer wrote:

 don't think it's worth adding them until we can have full 
 reflection capabilities so we can get at elements of code and 
 therefore get the annotations associated with it.  I see much more 
 usefulness for annotations as reflection hints than as a 
 replacement for keywords.


 But we already have full reflection. It's called __traits. You can 
 build a serialization library or "proper" (user friendly?) 
 reflection on top of it.


  I think you are the 1 millionth person to say it, and yet we still 
 do not have a "user friendly" reflection system.  Why is that?  You'd 
 think that if it could be done, somebody would have done it by now.


 The reality is there's quite few of us. D is not in the stage where if 
 something could be done, somebody somewhere has done it or is working 
 on it.


 
 That's understandable, nobody can expect a language as young as D to 
 have everything.
 
 But in reality, I think the *theory* that everything is there to build a 
 reflection system is only proven when it actually happens.  I'm sure 
 when the enterprising person or persons go to develop it, they will find 
 pieces missing from the static reflection system.


Exactly. I'm absolutely sure there are quite a few things needed here 
and there. I can assure you I'll push hard for those.


 So my point is that adding annotations before reflection works and is 
 implemented makes little sense to me, because the usage of them will be 
 crippled by the fact that reflection isn't complete.
 
 What I'd like to see is something like this possible:
 
 void foo (int timeout, string bar, float f = 4.0);
 
 void foo(int timeout);
 
 call!(foo)("timeout=5,bar=\"hello\"");
 
 Taking into account the default value of f, what the parameters are 



This is interesting. It means we'd need reflection for parameter names, 
which currently does not exist.


Andrei
Aug 04 2009
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Andrei Alexandrescu wrote:

 Steven Schveighoffer wrote:

 On Tue, 04 Aug 2009 12:23:41 -0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:


 Steven Schveighoffer wrote:

 On Tue, 04 Aug 2009 09:45:51 -0400, grauzone <none example.net> wrote:


 Steven Schveighoffer wrote:

 don't think it's worth adding them until we can have full 
 reflection capabilities so we can get at elements of code and 
 therefore get the annotations associated with it.  I see much more 
 usefulness for annotations as reflection hints than as a 
 replacement for keywords.


 But we already have full reflection. It's called __traits. You can 
 build a serialization library or "proper" (user friendly?) 
 reflection on top of it.


  I think you are the 1 millionth person to say it, and yet we still 
 do not have a "user friendly" reflection system.  Why is that?  
 You'd think that if it could be done, somebody would have done it by 
 now.


 The reality is there's quite few of us. D is not in the stage where 
 if something could be done, somebody somewhere has done it or is 
 working on it.


 That's understandable, nobody can expect a language as young as D to 
 have everything.

 But in reality, I think the *theory* that everything is there to build 
 a reflection system is only proven when it actually happens.  I'm sure 
 when the enterprising person or persons go to develop it, they will 
 find pieces missing from the static reflection system.


 
 Exactly. I'm absolutely sure there are quite a few things needed here 
 and there. I can assure you I'll push hard for those.
 

 So my point is that adding annotations before reflection works and is 
 implemented makes little sense to me, because the usage of them will 
 be crippled by the fact that reflection isn't complete.

 What I'd like to see is something like this possible:

 void foo (int timeout, string bar, float f = 4.0);

 void foo(int timeout);

 call!(foo)("timeout=5,bar=\"hello\"");

 Taking into account the default value of f, what the parameters are 



 
 This is interesting. It means we'd need reflection for parameter names, 
 which currently does not exist.


Why do it with strings? Why not

call!(foo)(5, "hello")

with varaidic args?
Aug 04 2009
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 04 Aug 2009 13:44:46 -0400, Ary Borenszweig <ary esperanto.org.ar>  
wrote:


 Andrei Alexandrescu wrote:

 Steven Schveighoffer wrote:

 What I'd like to see is something like this possible:

 void foo (int timeout, string bar, float f = 4.0);

 void foo(int timeout);

 call!(foo)("timeout=5,bar=\"hello\"");

 Taking into account the default value of f, what the parameters are  



  This is interesting. It means we'd need reflection for parameter  
 names, which currently does not exist.


 Why do it with strings? Why not

 call!(foo)(5, "hello")

 with varaidic args?


Ok, say foo is:

void foo(string bar, int timeout)

-Steve
Aug 04 2009
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Steven Schveighoffer wrote:

 On Tue, 04 Aug 2009 13:44:46 -0400, Ary Borenszweig 
 <ary esperanto.org.ar> wrote:
 

 Andrei Alexandrescu wrote:

 Steven Schveighoffer wrote:

 What I'd like to see is something like this possible:

 void foo (int timeout, string bar, float f = 4.0);

 void foo(int timeout);

 call!(foo)("timeout=5,bar=\"hello\"");

 Taking into account the default value of f, what the parameters are 



  This is interesting. It means we'd need reflection for parameter 
 names, which currently does not exist.


 Why do it with strings? Why not

 call!(foo)(5, "hello")

 with varaidic args?


 
 Ok, say foo is:
 
 void foo(string bar, int timeout)


What's the difference?
Aug 04 2009
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 04 Aug 2009 14:46:34 -0400, Ary Borenszweig <ary esperanto.org.ar>  
wrote:


 Steven Schveighoffer wrote:

 On Tue, 04 Aug 2009 13:44:46 -0400, Ary Borenszweig  
 <ary esperanto.org.ar> wrote:


 Andrei Alexandrescu wrote:

 Steven Schveighoffer wrote:

 What I'd like to see is something like this possible:

 void foo (int timeout, string bar, float f = 4.0);

 void foo(int timeout);

 call!(foo)("timeout=5,bar=\"hello\"");

 Taking into account the default value of f, what the parameters are  



  This is interesting. It means we'd need reflection for parameter  
 names, which currently does not exist.


 Why do it with strings? Why not

 call!(foo)(5, "hello")

 with varaidic args?


  Ok, say foo is:
  void foo(string bar, int timeout)


 What's the difference?


The difference is, I'm saying I want to call foo with parameters  
identified by parameter name, not parameter order.

-Steve
Aug 04 2009
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Ary Borenszweig wrote:

 Andrei Alexandrescu wrote:

 Steven Schveighoffer wrote:

 On Tue, 04 Aug 2009 12:23:41 -0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:


 Steven Schveighoffer wrote:

 On Tue, 04 Aug 2009 09:45:51 -0400, grauzone <none example.net> wrote:


 Steven Schveighoffer wrote:

 don't think it's worth adding them until we can have full 
 reflection capabilities so we can get at elements of code and 
 therefore get the annotations associated with it.  I see much 
 more usefulness for annotations as reflection hints than as a 
 replacement for keywords.


 But we already have full reflection. It's called __traits. You can 
 build a serialization library or "proper" (user friendly?) 
 reflection on top of it.


  I think you are the 1 millionth person to say it, and yet we still 
 do not have a "user friendly" reflection system.  Why is that?  
 You'd think that if it could be done, somebody would have done it 
 by now.


 The reality is there's quite few of us. D is not in the stage where 
 if something could be done, somebody somewhere has done it or is 
 working on it.


 That's understandable, nobody can expect a language as young as D to 
 have everything.

 But in reality, I think the *theory* that everything is there to 
 build a reflection system is only proven when it actually happens.  
 I'm sure when the enterprising person or persons go to develop it, 
 they will find pieces missing from the static reflection system.


 Exactly. I'm absolutely sure there are quite a few things needed here 
 and there. I can assure you I'll push hard for those.


 So my point is that adding annotations before reflection works and is 
 implemented makes little sense to me, because the usage of them will 
 be crippled by the fact that reflection isn't complete.

 What I'd like to see is something like this possible:

 void foo (int timeout, string bar, float f = 4.0);

 void foo(int timeout);

 call!(foo)("timeout=5,bar=\"hello\"");

 Taking into account the default value of f, what the parameters are 



 This is interesting. It means we'd need reflection for parameter 
 names, which currently does not exist.


 
 Why do it with strings? Why not
 
 call!(foo)(5, "hello")
 
 with varaidic args?


Well some don't like to need to remember the order of arguments.

Andrei
Aug 04 2009
next sibling parent reply Frank Benoit <keinfarbton googlemail.com> writes:
Andrei Alexandrescu schrieb:

 Ary Borenszweig wrote:

 call!(foo)(5, "hello")

 with varaidic args?


 
 Well some don't like to need to remember the order of arguments.
 
 Andrei


Assigning the argument by name instead of order has two other benefits,
i can think of...
1. on the call side, it is documented for what the given values are used.
2. it may be possible to let all parameters have default values and for
example just give a value for the last parameter. This is not possible
with just the parameter order.
Aug 04 2009
parent reply Benji Smith <dlanguage benjismith.net> writes:
Frank Benoit wrote:

 Andrei Alexandrescu schrieb:

 Ary Borenszweig wrote:

 call!(foo)(5, "hello")

 with varaidic args?


 Well some don't like to need to remember the order of arguments.

 Andrei


 
 Assigning the argument by name instead of order has two other benefits,
 i can think of...
 1. on the call side, it is documented for what the given values are used.
 2. it may be possible to let all parameters have default values and for
 example just give a value for the last parameter. This is not possible
 with just the parameter order.


But these aren't issues with reflection. These are just the same 
function calling rules applied elsewhere in the language:

1) If you want to call a function: you must know its name.

2) If you want to pass parameters: you must know the correct order.

I can't imagine a circumstance where someone uses reflection to call a 
function and knows how to create the correct set of arguments, but 
doesn't know what order to put them in.

--benji
Aug 04 2009
parent "Denis Koroskin" <2korden gmail.com> writes:
On Wed, 05 Aug 2009 07:20:38 +0400, Benji Smith <dlanguage benjismith.net>  
wrote:


 Frank Benoit wrote:

 Andrei Alexandrescu schrieb:

 Ary Borenszweig wrote:

 call!(foo)(5, "hello")

 with varaidic args?


 Well some don't like to need to remember the order of arguments.

 Andrei


  Assigning the argument by name instead of order has two other benefits,
 i can think of...
 1. on the call side, it is documented for what the given values are  
 used.
 2. it may be possible to let all parameters have default values and for
 example just give a value for the last parameter. This is not possible
 with just the parameter order.


 But these aren't issues with reflection. These are just the same  
 function calling rules applied elsewhere in the language:

 1) If you want to call a function: you must know its name.

 2) If you want to pass parameters: you must know the correct order.

 I can't imagine a circumstance where someone uses reflection to call a  
 function and knows how to create the correct set of arguments, but  
 doesn't know what order to put them in.

 --benji



They are mostly used with optional parameters:

void foo(int x = -1, int y = 42, bool b = false);

foo(b: true);
Aug 05 2009
prev sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Andrei Alexandrescu wrote:

 Ary Borenszweig wrote:

 Andrei Alexandrescu wrote:

 Steven Schveighoffer wrote:

 On Tue, 04 Aug 2009 12:23:41 -0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:


 Steven Schveighoffer wrote:

 On Tue, 04 Aug 2009 09:45:51 -0400, grauzone <none example.net> 
 wrote:


 Steven Schveighoffer wrote:

 don't think it's worth adding them until we can have full 
 reflection capabilities so we can get at elements of code and 
 therefore get the annotations associated with it.  I see much 
 more usefulness for annotations as reflection hints than as a 
 replacement for keywords.


 But we already have full reflection. It's called __traits. You 
 can build a serialization library or "proper" (user friendly?) 
 reflection on top of it.


  I think you are the 1 millionth person to say it, and yet we 
 still do not have a "user friendly" reflection system.  Why is 
 that?  You'd think that if it could be done, somebody would have 
 done it by now.


 The reality is there's quite few of us. D is not in the stage where 
 if something could be done, somebody somewhere has done it or is 
 working on it.


 That's understandable, nobody can expect a language as young as D to 
 have everything.

 But in reality, I think the *theory* that everything is there to 
 build a reflection system is only proven when it actually happens.  
 I'm sure when the enterprising person or persons go to develop it, 
 they will find pieces missing from the static reflection system.


 Exactly. I'm absolutely sure there are quite a few things needed here 
 and there. I can assure you I'll push hard for those.


 So my point is that adding annotations before reflection works and 
 is implemented makes little sense to me, because the usage of them 
 will be crippled by the fact that reflection isn't complete.

 What I'd like to see is something like this possible:

 void foo (int timeout, string bar, float f = 4.0);

 void foo(int timeout);

 call!(foo)("timeout=5,bar=\"hello\"");

 Taking into account the default value of f, what the parameters are 



 This is interesting. It means we'd need reflection for parameter 
 names, which currently does not exist.


 Why do it with strings? Why not

 call!(foo)(5, "hello")

 with varaidic args?


 
 Well some don't like to need to remember the order of arguments.


But that's a way totally different thing discussed here.

First you need to introduce argument names when invoking a function.

void foo(int timeout, string bar) {
    ..
}

Can be used as:

foo(timeout=5, bar="100")

(with some other syntax, of course)

Once you have that, you could do:

call!(foo)(timeout=5, bar="100")

Voilà!
Aug 04 2009
next sibling parent Ary Borenszweig <ary esperanto.org.ar> writes:
Ary Borenszweig wrote:

 Andrei Alexandrescu wrote:

 Ary Borenszweig wrote:

 Andrei Alexandrescu wrote:

 Steven Schveighoffer wrote:

 On Tue, 04 Aug 2009 12:23:41 -0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:


 Steven Schveighoffer wrote:

 On Tue, 04 Aug 2009 09:45:51 -0400, grauzone <none example.net> 
 wrote:


 Steven Schveighoffer wrote:

 don't think it's worth adding them until we can have full 
 reflection capabilities so we can get at elements of code and 
 therefore get the annotations associated with it.  I see much 
 more usefulness for annotations as reflection hints than as a 
 replacement for keywords.


 But we already have full reflection. It's called __traits. You 
 can build a serialization library or "proper" (user friendly?) 
 reflection on top of it.


  I think you are the 1 millionth person to say it, and yet we 
 still do not have a "user friendly" reflection system.  Why is 
 that?  You'd think that if it could be done, somebody would have 
 done it by now.


 The reality is there's quite few of us. D is not in the stage 
 where if something could be done, somebody somewhere has done it 
 or is working on it.


 That's understandable, nobody can expect a language as young as D 
 to have everything.

 But in reality, I think the *theory* that everything is there to 
 build a reflection system is only proven when it actually happens.  
 I'm sure when the enterprising person or persons go to develop it, 
 they will find pieces missing from the static reflection system.


 Exactly. I'm absolutely sure there are quite a few things needed 
 here and there. I can assure you I'll push hard for those.


 So my point is that adding annotations before reflection works and 
 is implemented makes little sense to me, because the usage of them 
 will be crippled by the fact that reflection isn't complete.

 What I'd like to see is something like this possible:

 void foo (int timeout, string bar, float f = 4.0);

 void foo(int timeout);

 call!(foo)("timeout=5,bar=\"hello\"");

 Taking into account the default value of f, what the parameters are 



 This is interesting. It means we'd need reflection for parameter 
 names, which currently does not exist.


 Why do it with strings? Why not

 call!(foo)(5, "hello")

 with varaidic args?


 Well some don't like to need to remember the order of arguments.


 
 But that's a way totally different thing discussed here.


Sorry, not totally different. What I'm saying is: one thing at a time.
Aug 04 2009
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 04 Aug 2009 15:56:16 -0400, Ary Borenszweig <ary esperanto.org.ar>  
wrote:


 Andrei Alexandrescu wrote:

  Well some don't like to need to remember the order of arguments.


 But that's a way totally different thing discussed here.

 First you need to introduce argument names when invoking a function.

 void foo(int timeout, string bar) {
     ..
 }

 Can be used as:

 foo(timeout=5, bar="100")

 (with some other syntax, of course)

 Once you have that, you could do:

 call!(foo)(timeout=5, bar="100")

 Voilà!


It could also be accomplished via a fully implemented reflection library,  
which is my side topic for this thread branch :P


support named parameters.

-Steve
Aug 04 2009
next sibling parent Ary Borenszweig <ary esperanto.org.ar> writes:
Steven Schveighoffer wrote:

 On Tue, 04 Aug 2009 15:56:16 -0400, Ary Borenszweig 
 <ary esperanto.org.ar> wrote:
 

 Andrei Alexandrescu wrote:

  Well some don't like to need to remember the order of arguments.


 But that's a way totally different thing discussed here.

 First you need to introduce argument names when invoking a function.

 void foo(int timeout, string bar) {
     ..
 }

 Can be used as:

 foo(timeout=5, bar="100")

 (with some other syntax, of course)

 Once you have that, you could do:

 call!(foo)(timeout=5, bar="100")

 Voilà!


 
 It could also be accomplished via a fully implemented reflection 
 library, which is my side topic for this thread branch :P
 

 support named parameters.


Aaaaaaah... I see now. :)
Aug 04 2009
prev sibling next sibling parent reply Rainer Deyke <rainerd eldwood.com> writes:
Steven Schveighoffer wrote:

 On Tue, 04 Aug 2009 15:56:16 -0400, Ary Borenszweig
 <ary esperanto.org.ar> wrote:

 foo(timeout=5, bar="100")


 It could also be accomplished via a fully implemented reflection
 library, which is my side topic for this thread branch :P


No.  The names of positional arguments are an implementation detail, and
should not be exposed via reflection.  Named arguments are different
from positional arguments and require separate language support.

Consider the ambiguity caused by function overloading:
  void f(int x, string y);
  void f(string y, int x);
  f(x = 1, y = "");

Consider the implications of function pointers:
  void f(int x, int y);
  void g(int y, int x);
  (cond ? &f : &g)(x = 1, y = 2);


-- 
Rainer Deyke - rainerd eldwood.com
Aug 04 2009
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 04 Aug 2009 17:20:53 -0400, Rainer Deyke <rainerd eldwood.com>  
wrote:


 Steven Schveighoffer wrote:

 On Tue, 04 Aug 2009 15:56:16 -0400, Ary Borenszweig
 <ary esperanto.org.ar> wrote:

 foo(timeout=5, bar="100")


 It could also be accomplished via a fully implemented reflection
 library, which is my side topic for this thread branch :P


 No.  The names of positional arguments are an implementation detail, and
 should not be exposed via reflection.  Named arguments are different
 from positional arguments and require separate language support.


It works.  See  
http://msdn.microsoft.com/en-us/library/system.reflection.parameterinfo.name.aspx


 Consider the ambiguity caused by function overloading:
   void f(int x, string y);
   void f(string y, int x);
   f(x = 1, y = "");


That is a case where the proposed function would throw an exception.


 Consider the implications of function pointers:
   void f(int x, int y);
   void g(int y, int x);
   (cond ? &f : &g)(x = 1, y = 2);


I don't see what this has to do with reflection...

-Steve
Aug 04 2009
prev sibling parent John C <johnch_atms hotmail.com> writes:
Steven Schveighoffer wrote:

 

 support named parameters.


But they're coming: 
http://msdn.microsoft.com/en-us/library/dd264739(VS.100).aspx
Aug 04 2009
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 8/4/09 19:20, Andrei Alexandrescu wrote:

 Steven Schveighoffer wrote:

 On Tue, 04 Aug 2009 12:23:41 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:


 Steven Schveighoffer wrote:

 On Tue, 04 Aug 2009 09:45:51 -0400, grauzone <none example.net> wrote:


 Steven Schveighoffer wrote:

 don't think it's worth adding them until we can have full
 reflection capabilities so we can get at elements of code and
 therefore get the annotations associated with it. I see much more
 usefulness for annotations as reflection hints than as a
 replacement for keywords.


 But we already have full reflection. It's called __traits. You can
 build a serialization library or "proper" (user friendly?)
 reflection on top of it.


 I think you are the 1 millionth person to say it, and yet we still
 do not have a "user friendly" reflection system. Why is that? You'd
 think that if it could be done, somebody would have done it by now.


 The reality is there's quite few of us. D is not in the stage where
 if something could be done, somebody somewhere has done it or is
 working on it.


 That's understandable, nobody can expect a language as young as D to
 have everything.

 But in reality, I think the *theory* that everything is there to build
 a reflection system is only proven when it actually happens. I'm sure
 when the enterprising person or persons go to develop it, they will
 find pieces missing from the static reflection system.


 Exactly. I'm absolutely sure there are quite a few things needed here
 and there. I can assure you I'll push hard for those.


 So my point is that adding annotations before reflection works and is
 implemented makes little sense to me, because the usage of them will
 be crippled by the fact that reflection isn't complete.

 What I'd like to see is something like this possible:

 void foo (int timeout, string bar, float f = 4.0);

 void foo(int timeout);

 call!(foo)("timeout=5,bar=\"hello\"");

 Taking into account the default value of f, what the parameters are



 This is interesting. It means we'd need reflection for parameter names,
 which currently does not exist.


 Andrei


It kind of exists:

void foo (int bar);

const str = typeof(&func).stringof;

"str" will contain the parameter names. See: 
http://tango.pastebin.com/m129241b0 for an example.
Aug 04 2009
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 8/4/09 18:55, Steven Schveighoffer wrote:

 On Tue, 04 Aug 2009 12:23:41 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:


 Steven Schveighoffer wrote:

 On Tue, 04 Aug 2009 09:45:51 -0400, grauzone <none example.net> wrote:


 Steven Schveighoffer wrote:

 don't think it's worth adding them until we can have full
 reflection capabilities so we can get at elements of code and
 therefore get the annotations associated with it. I see much more
 usefulness for annotations as reflection hints than as a
 replacement for keywords.


 But we already have full reflection. It's called __traits. You can
 build a serialization library or "proper" (user friendly?)
 reflection on top of it.


 I think you are the 1 millionth person to say it, and yet we still do
 not have a "user friendly" reflection system. Why is that? You'd
 think that if it could be done, somebody would have done it by now.


 The reality is there's quite few of us. D is not in the stage where if
 something could be done, somebody somewhere has done it or is working
 on it.


 That's understandable, nobody can expect a language as young as D to
 have everything.

 But in reality, I think the *theory* that everything is there to build a
 reflection system is only proven when it actually happens. I'm sure when
 the enterprising person or persons go to develop it, they will find
 pieces missing from the static reflection system.

 So my point is that adding annotations before reflection works and is
 implemented makes little sense to me, because the usage of them will be
 crippled by the fact that reflection isn't complete.

 What I'd like to see is something like this possible:

 void foo (int timeout, string bar, float f = 4.0);

 void foo(int timeout);

 call!(foo)("timeout=5,bar=\"hello\"");

 Taking into account the default value of f, what the parameters are


 -Steve


You mean like this: http://tango.pastebin.com/m129241b0 ?

/Jacob Carlborg
Aug 04 2009
next sibling parent Jacob Carlborg <doob me.com> writes:
On 8/5/09 00:22, Jacob Carlborg wrote:

 On 8/4/09 18:55, Steven Schveighoffer wrote:

 On Tue, 04 Aug 2009 12:23:41 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:


 Steven Schveighoffer wrote:

 On Tue, 04 Aug 2009 09:45:51 -0400, grauzone <none example.net> wrote:


 Steven Schveighoffer wrote:

 don't think it's worth adding them until we can have full
 reflection capabilities so we can get at elements of code and
 therefore get the annotations associated with it. I see much more
 usefulness for annotations as reflection hints than as a
 replacement for keywords.


 But we already have full reflection. It's called __traits. You can
 build a serialization library or "proper" (user friendly?)
 reflection on top of it.


 I think you are the 1 millionth person to say it, and yet we still do
 not have a "user friendly" reflection system. Why is that? You'd
 think that if it could be done, somebody would have done it by now.


 The reality is there's quite few of us. D is not in the stage where if
 something could be done, somebody somewhere has done it or is working
 on it.


 That's understandable, nobody can expect a language as young as D to
 have everything.

 But in reality, I think the *theory* that everything is there to build a
 reflection system is only proven when it actually happens. I'm sure when
 the enterprising person or persons go to develop it, they will find
 pieces missing from the static reflection system.

 So my point is that adding annotations before reflection works and is
 implemented makes little sense to me, because the usage of them will be
 crippled by the fact that reflection isn't complete.

 What I'd like to see is something like this possible:

 void foo (int timeout, string bar, float f = 4.0);

 void foo(int timeout);

 call!(foo)("timeout=5,bar=\"hello\"");

 Taking into account the default value of f, what the parameters are


 -Steve


 You mean like this: http://tango.pastebin.com/m129241b0 ?

 /Jacob Carlborg


Forgot to say: this works in D1 with dmd, gdc and ldc.

/Jacob Carlborg
Aug 04 2009
prev sibling parent Don <nospam nospam.com> writes:
Jacob Carlborg wrote:

 On 8/4/09 18:55, Steven Schveighoffer wrote:

 On Tue, 04 Aug 2009 12:23:41 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:


 Steven Schveighoffer wrote:

 On Tue, 04 Aug 2009 09:45:51 -0400, grauzone <none example.net> wrote:


 Steven Schveighoffer wrote:

 don't think it's worth adding them until we can have full
 reflection capabilities so we can get at elements of code and
 therefore get the annotations associated with it. I see much more
 usefulness for annotations as reflection hints than as a
 replacement for keywords.


 But we already have full reflection. It's called __traits. You can
 build a serialization library or "proper" (user friendly?)
 reflection on top of it.


 I think you are the 1 millionth person to say it, and yet we still do
 not have a "user friendly" reflection system. Why is that? You'd
 think that if it could be done, somebody would have done it by now.


 The reality is there's quite few of us. D is not in the stage where if
 something could be done, somebody somewhere has done it or is working
 on it.


 That's understandable, nobody can expect a language as young as D to
 have everything.

 But in reality, I think the *theory* that everything is there to build a
 reflection system is only proven when it actually happens. I'm sure when
 the enterprising person or persons go to develop it, they will find
 pieces missing from the static reflection system.

 So my point is that adding annotations before reflection works and is
 implemented makes little sense to me, because the usage of them will be
 crippled by the fact that reflection isn't complete.

 What I'd like to see is something like this possible:

 void foo (int timeout, string bar, float f = 4.0);

 void foo(int timeout);

 call!(foo)("timeout=5,bar=\"hello\"");

 Taking into account the default value of f, what the parameters are


 -Steve


 
 You mean like this: http://tango.pastebin.com/m129241b0 ?
 
 /Jacob Carlborg


static assert(jacobCarlbord.ninjaLevel == BlackBelt);
Aug 05 2009
prev sibling parent KennyTM~ <kennytm gmail.com> writes:
Don wrote:

 Ary Borenszweig wrote:

 Don escribió:

 grauzone wrote:

 Don wrote:

 Ary Borenszweig wrote:

 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6


 This looks like a solution in search of a problem. What's the 
 problem being solved?


 Attaching additional data to types, that can't be specified 
 otherwhere. This should help with metaprogramming-like stuff.

 For example serialization. How do you specify that a field shouldn't 
 be part of the serialized data? Java has an extra keyword attribute 
 like

 what we call annotation in this thread. How would you do this in D?


 I agree that there doesn't seem to be a nice way at present. One 
 possibility would be to establish a naming convention for transient 
 fields -- a Ruby-style solution, I guess.

 But are annotations actually an ideal solution for this problem?
 Presumably, you'll have to specify that somewhere else anyway. I 
 mean, during reading it will need to either be initialized separately 
 after serialisation (like opPostBlit, perhaps?), or else remain 
 uninitialized. Serialisation seems to be _extremely_ similar to 
 construction. I'm not sure that annotations capture that.


 intuition and hope is that we shouldn't need to adopt hacks from 

 like an ugly hack to me. Purely a subjective opinion, of course, but 
 it seems really out of place in a C-family language.


 Attributes has many, many other uses. Appart from serialization, you 
 could specify how a field is stored in a database. How a method maps 
 to an http request (post, get, which parameters to bind to the 
 request, etc.). Whether a method should do security checks before 
 executing. Whether a method should be run as a test, and what's the 
 expected exception to be thrown. [insert your usage here]


 
 Great, you've answered my question. That should be in the DIP, instead 
 of the vague stuff that's in there now -- the existing DIP is about 
 replacing keywords, which is very unconvincing. (It doesn't work, 
 actually -- the name mangling is important for most of the keywords 
 mentioned).


The compiler can recognize special annotations and put them to the name 
mangling. It may even mangle general purpose annotations.
Aug 03 2009
prev sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
grauzone wrote:

 Don wrote:

 Ary Borenszweig wrote:

 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6


 This looks like a solution in search of a problem. What's the problem
 being solved?


 
 Attaching additional data to types, that can't be specified otherwhere.
 This should help with metaprogramming-like stuff.
 
 For example serialization. How do you specify that a field shouldn't be
 part of the serialized data? Java has an extra keyword attribute like

 we call annotation in this thread. How would you do this in D?


struct Foo
{
    int serialise_me, dont_serialise_me, or_me;

    alias Tuple!("dont_serialise_me", "or_me") IgnoreForSerialisation;
}

Or, if you'd rather have a less hacky interface:

struct Foo
{
    int serialise_me, dont_serialise_me, or_me;

    mixin IgnoreForSerialisation!("dont_serialise_me", "or_me");
}
Aug 03 2009
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Daniel Keep wrote:

 
 grauzone wrote:

 Don wrote:

 Ary Borenszweig wrote:

 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6


 This looks like a solution in search of a problem. What's the problem
 being solved?


 Attaching additional data to types, that can't be specified otherwhere.
 This should help with metaprogramming-like stuff.

 For example serialization. How do you specify that a field shouldn't be
 part of the serialized data? Java has an extra keyword attribute like

 we call annotation in this thread. How would you do this in D?


 
 struct Foo
 {
     int serialise_me, dont_serialise_me, or_me;
 
     alias Tuple!("dont_serialise_me", "or_me") IgnoreForSerialisation;
 }
 
 Or, if you'd rather have a less hacky interface:
 
 struct Foo
 {
     int serialise_me, dont_serialise_me, or_me;
 
     mixin IgnoreForSerialisation!("dont_serialise_me", "or_me");
 }


I can imagine this also:

struct Foo {
	char[] one;
         int two;
	float three;

	mixin SerializeAsXmlElement!("one", "desiredNameForOne", "two", 
"desiredNameForTwo");

	mixin SerializeAsXmlAttribute!("three", "desiredNameForThree");
}

That looks great. And as your struct grows, you have to scroll down to 
see how an element is serialized. And if you want to change how an 
element is serialized you scroll down and move two strings from one 
point to another. I also wonder *how* is that mixed template 
implemented, it probably adds some fields or things to that struct.

How about this:

struct Foo {

	 XmlElement("desiredNameForOne");
	char[] one;

	 XmlElement("desiredNameForTwo");
	int two;

	 XmlAttribute("desiredNameForThree");
	float three;
}

Which one looks nicer and more understandable to you? How do you change 
a property to be serialized as an element to an attribute? You just 
change "XmlElement" to "XmlAttribute" and that's it.

Your approach also is no DRY: you have to name the fields again. It 
might throw awful compiler errors for template code when you mistype 
something. If you rename a field you must also remember to rename the 
serialization mixin.
Aug 03 2009
parent Daniel Keep <daniel.keep.lists gmail.com> writes:
Ary Borenszweig wrote:

 Daniel Keep wrote:

 grauzone wrote:

 ...
 For example serialization. How do you specify that a field shouldn't be
 part of the serialized data? Java has an extra keyword attribute like

 we call annotation in this thread. How would you do this in D?


 struct Foo
 {
     int serialise_me, dont_serialise_me, or_me;

     alias Tuple!("dont_serialise_me", "or_me") IgnoreForSerialisation;
 }

 Or, if you'd rather have a less hacky interface:

 struct Foo
 {
     int serialise_me, dont_serialise_me, or_me;

     mixin IgnoreForSerialisation!("dont_serialise_me", "or_me");
 }


 
 ...
 
 That looks great. And as your struct grows, you have to scroll down to
 see how an element is serialized. And if you want to change how an
 element is serialized you scroll down and move two strings from one
 point to another. I also wonder *how* is that mixed template
 implemented, it probably adds some fields or things to that struct.


"How would you do this in D?"

I was answering the question.


 How about this:
 
 struct Foo {
 
      XmlElement("desiredNameForOne");
     char[] one;
 
      XmlElement("desiredNameForTwo");
     int two;
 
      XmlAttribute("desiredNameForThree");
     float three;
 }
 
 Which one looks nicer and more understandable to you? How do you change
 a property to be serialized as an element to an attribute? You just
 change "XmlElement" to "XmlAttribute" and that's it.


Which one works right now and doesn't require you first spend at least a
year convincing Walter that it's useful, then convincing him it's
necessary, followed by six months of continuous bike-shedding by the
community before Walter gives up and implements something that somehow
manages to piss off everyone who was arguing for it, largely because it
wasn't the exact syntax they wanted?

Which one have I been successfully using in a project of mine for over
two and a half years now thanks to it also working in crusty old D1?

Who's the one with a working struct->xml parser template based on it?


 Your approach also is no DRY: you have to name the fields again. It
 might throw awful compiler errors for template code when you mistype
 something. If you rename a field you must also remember to rename the
 serialization mixin.


It's odd; I can't find the part of my post where I said this was perfect
and the ideal solution!  My newsreader must be truncating my messages...
Aug 03 2009
prev sibling parent reply Max Samukha <spambox d-coding.com> writes:
On Tue, 04 Aug 2009 01:30:29 +1000, Daniel Keep
<daniel.keep.lists gmail.com> wrote:


grauzone wrote:

 Don wrote:

 Ary Borenszweig wrote:

 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6


 This looks like a solution in search of a problem. What's the problem
 being solved?


 
 Attaching additional data to types, that can't be specified otherwhere.
 This should help with metaprogramming-like stuff.
 
 For example serialization. How do you specify that a field shouldn't be
 part of the serialized data? Java has an extra keyword attribute like

 we call annotation in this thread. How would you do this in D?


struct Foo
{
    int serialise_me, dont_serialise_me, or_me;

    alias Tuple!("dont_serialise_me", "or_me") IgnoreForSerialisation;
}

Or, if you'd rather have a less hacky interface:

struct Foo
{
    int serialise_me, dont_serialise_me, or_me;

    mixin IgnoreForSerialisation!("dont_serialise_me", "or_me");
}


You can even use a mixin per member:

struct Foo
{
    mixin Persistent!("field", "field-as-it-is-named-in-db");
    int field;
    
    mixin Persistent!("field2");
    mixin Serializable!("field2"); 
    int field2;
}

It would be nice (and that is unlikely to happen) if the compiler
could rewrite

struct Foo
{
     Persistent("db_field")
     Serializable
    int field;
}

to

struct Foo
{
    int field;
    mixin Persistent!("field", "db_field");
    mixin Serializable!("field");
}
Aug 03 2009
parent grauzone <none example.net> writes:
Max Samukha wrote:

 It would be nice (and that is unlikely to happen) if the compiler
 could rewrite
 
 struct Foo
 {
      Persistent("db_field")
      Serializable
     int field;
 }
 
 to
 
 struct Foo
 {
     int field;
     mixin Persistent!("field", "db_field");
     mixin Serializable!("field");
 }
 


It'd be even nicer if it wouldn't require ridiculous hacks from you to 
read out the annotation data again.

E.g. right now, that Serializable mixin would define something like 
"const bool field_serializeable = true;", and you'd need to use CTFE 
string concatenation (better hope the compiler's GC is enabled) and is() 
to define/read the data. Very clumsy and hackish, although it would work.

For me, making these things simpler is the whole point of annotations.

Looks like we have three basic things that annotations could be used for:
1. alternative namespace for keywords
2. associate arbitrary, user defined metadata with types and fields
3. macro madness (using the approach found in Python)
Aug 03 2009
prev sibling next sibling parent Kagamin <spam here.lot> writes:
Don Wrote:


 Ary Borenszweig wrote:

 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6


 
 This looks like a solution in search of a problem. What's the problem 
 being solved?


Lack of power. People today want powerful language. With attributes you can
arbitrarily extend metadata, see AttributeTargets enumeration
http://msdn.microsoft.com/en-us/library/system.attributetargets.aspx
Aug 03 2009
prev sibling parent Benji Smith <dlanguage benjismith.net> writes:
Don wrote:

 Ary Borenszweig wrote:

 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6


 
 This looks like a solution in search of a problem. What's the problem 
 being solved?


Keyword proliferation for a zillion tiny features? Annotations would 
help with that very nicely.

--benji
Aug 03 2009
prev sibling next sibling parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
Ary Borenszweig wrote:

 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6



I like the idea of attributes having names that can never be 
identifiers, since adding new attributes will then, as you point out, 
never break existing code.

But won't we lose this benefit if we later allow user-defined annotations?

-Lars
Aug 03 2009
parent Ary Borenszweig <ary esperanto.org.ar> writes:
Lars T. Kyllingstad escribió:

 Ary Borenszweig wrote:

 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6


 
 
 I like the idea of attributes having names that can never be 
 identifiers, since adding new attributes will then, as you point out, 
 never break existing code.
 
 But won't we lose this benefit if we later allow user-defined annotations?


Kind of, but not totally. If you allow user-defined annotations, they 
need to be placed in a module, so they have a fully qualified name. You 
could have an foo.bar.align annotation (supposing "align" was already an 
annotation) and do:

 foo.bar.align
int x;

The compiler-instrinsic annotations would be defined in module object or 
something like that.

That way you can disambiguate annotations with same names.
Aug 03 2009
prev sibling next sibling parent Kagamin <spam here.lot> writes:
Ary Borenszweig Wrote:


 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6


VB uses angle brackets to delimit attributes. They usually don't repeat, only
chain... unless you want to put them in strange places...
Aug 03 2009
prev sibling next sibling parent Daniel Keep <daniel.keep.lists gmail.com> writes:
I'd rather see this put off until we have macros; then steal the syntax
to mean the same thing it does in Python.
Aug 03 2009
prev sibling next sibling parent reply Yigal Chripun <yigal100 gmail.com> writes:
grauzone Wrote:


 yigal chripun wrote:

 this is a good start but as already noted by others, you can't specify types
with structs. we also can't use type tuples cause of the auto flatten behavior. 


 
 And why can't we use structs? Unless I've missed something, it wasn't 
 explained in this thread.


how can you pass types as arguments to your annotation if that annotation is a
struct? 
for instance, what would be the struct for:
  my_annotation(int, 4)
Aug 03 2009
parent Sergey Gromov <snake.scaly gmail.com> writes:
Mon, 03 Aug 2009 15:16:25 -0400, Yigal Chripun wrote:


 grauzone Wrote:
 

 yigal chripun wrote:

 this is a good start but as already noted by others, you can't specify types
with structs. we also can't use type tuples cause of the auto flatten behavior. 


 
 And why can't we use structs? Unless I've missed something, it wasn't 
 explained in this thread.


 
 how can you pass types as arguments to your annotation if that annotation is a
struct? 
 for instance, what would be the struct for:
   my_annotation(int, 4)


Perhaps  my_annotation!int(4)
Aug 03 2009
prev sibling next sibling parent yigal chripun <yigal100 gmail.com> writes:
Steven Schveighoffer Wrote:

 
 Yes, they have to be.  There are reasons besides overloading for including  
 other attributes in the naming.
 
 For example, if a function is pure, then becomes unpure, you don't  
 existing code that is expecting a pure function to link against it.
 
 In other words, the linker is dumb.  It only knows how to match symbols,  
 so you have to embed into the symbols the important pieces of the  
 interface that you want the linker to consider important.
 
 To answer Don's point, there is nothing saying that the compiler can't  
 read attributes and change its behavior.  Of course, those would have to  
 be builtin attributes.
 
 My opinion on removing existing keywords is -- don't.  There's little to  
 no gain.  Let that ship sail, and concentrate on future keyword proposals.
 
 -Steve


If we are willing to have our own specialized linker format than the compiler
can output data structures that contain a symbol with an assosiated map of
attributes (meta-data). This will remove the need to have mangled symbols. For
example, the compiler can provide to the linker the dependency graph as
attributes.
Aug 04 2009
prev sibling next sibling parent reply Kagamin <spam here.lot> writes:
grauzone Wrote:


 inheritance?


 
 You want to inherit annotations? What for?


Backward compatibility: obtain annotation cast it, work with it, then later
change its type. Annotations will be used by reflection, so classinfo will be
useful.
Aug 04 2009
parent grauzone <none example.net> writes:
Kagamin wrote:

 grauzone Wrote:
 

 inheritance?


 You want to inherit annotations? What for?


 
 Backward compatibility: obtain annotation cast it, work with it, then later
change its type. Annotations will be used by reflection, so classinfo will be
useful.


Code can do that at compiletime. No need for casting, because the tuple 
returned by __traits will use the "correct" types directly.

For runtime, I have no idea. The D crowd seems to prefer compile time. 
We got __traits instead of more detailed TypeInfo/ClassInfo. If you want 
to do runtime stuff, you'll have to generate your own RTTI using compile 
time code.
Aug 04 2009
prev sibling next sibling parent Kagamin <spam here.lot> writes:
Don Wrote:


 Annotations are useful in many ways, but without full reflection 
 capabilities, they are restricted to things that can read them via 
 source code, and so they are no better than comments.


 
 This is a very, very important observation, and I think it belongs in 
 the DIP. It means that it probably doesn't make much sense to implement 
 annotations without also having an intention to implement full-blown 
 reflection.


The DIP is about the first step: to allow syntax.
Aug 04 2009
prev sibling next sibling parent Kagamin <spam here.lot> writes:
Daniel Keep Wrote:


 Which one works right now and doesn't require you first spend at least a
 year convincing Walter that it's useful, then convincing him it's
 necessary


As far as I see, necessity is not questioned. It may be only of low priority or
something like that.
Aug 04 2009
prev sibling parent Kagamin <spam here.lot> writes:
Steven Schveighoffer Wrote:


 What I'd like to see is something like this possible:
 
 void foo (int timeout, string bar, float f = 4.0);
 
 void foo(int timeout);
 
 call!(foo)("timeout=5,bar=\"hello\"");
 
 Taking into account the default value of f, what the parameters are named,  



In .net reflection needs no compile time support, it's fully runtime. You don't
always have full type information at compile time, unless you want to restrict
reflection to compile-everyting-to-one-big-pile scenario.
Aug 05 2009