www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Custom attributes (again)

reply Manu <turkeyman gmail.com> writes:
--20cf30050ec00e08e504bced48c1
Content-Type: text/plain; charset=UTF-8

I just want to add more real-world experience to the controversy.
I'm finding myself needing to use custom attributes almost every day.

I have numerous systems that need to scan the module for things marked
accordingly to automate bindings to their respective systems.

This is my current list of attributes I want to mark things with:
  Export to game engine
  Export to script language
  Import from game engine
  ** Import from script language (tentative, I'm sure I'll need it in a few
more days)
  Expose to editor (with additional properties; description, edit type, etc)
  Serialise (load/save game)
  Replay serialisation (a different kind of serialisation that works with
different data sets)

And others I've encountered in passing that I can't recall right now.

As you can imagine, any attempt to 'work around' the lack of an attribute
system, ie, (ab)using enums, etc as have been suggested, leads to a big
mess in the context of all these requirements.
Management of such lists of stuff in disconnected places in code is time
consuming, thoroughly annoying, error-prone, difficult to maintain, and
leaves programmers with the bitter taste of C++.
Alternatively, wrapping virtually every single declaration made in mixin()
and declaring everything as strings is even more nasty, and the contrast
between mixin() declarations and 'normal' declarations looks completely
stupid. (Totally unreadable + difficult to understand, breaks intellisense,
code completion, syntax hilighting, etc... ie, unusable)

Does anyone have a *realistic* suggestion for emulating custom attributes?
Something that doesn't have any(/many) of the side effects I mention?
I haven't come up with anything that's acceptable yet.

If not, I assert that D absolutely needs a custom attribute system. For us
here, this will enable D the single biggest advantage over using C++ in the
same context that I've identified so far.
D's meta-programming is amazing, but sadly, proving pointless to me right
now without being able to mark stuff appropriately. All the meta magic is
hovering just out of my grasp, due to the fact I have no way to indicate
what items should involve with what systems.
Currently, I have to maintain big registry tables of junk that must be
amended/updated any time anyone adds/changes anything... and I'm feeling
rather embarrassed when I tell the other non-D programmers that they just
need to update this table here... and here... and make sure that's in sync
too before their stuff will just 'magically' work ;)

C# and Java both have attributes, following these established design
patterns, I don't think there should be any mystery over how they should be
implemented.

--20cf30050ec00e08e504bced48c1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div>I just want to add more real-world experience to the=C2=A0controversy.=
</div>I&#39;m finding myself needing to use custom attributes almost every =
day.<div><br></div><div><div>I have numerous systems that need to scan the =
module for things marked accordingly to automate bindings to their respecti=
ve systems.</div>
<br class=3D"Apple-interchange-newline"></div><div>This is my current list =
of attributes I want to mark things with:</div><div>=C2=A0 Export to game e=
ngine</div><div>=C2=A0 Export to script language</div><div>=C2=A0 Import fr=
om game engine</div>
<div>=C2=A0 ** Import from script language (tentative, I&#39;m sure I&#39;l=
l need it in a few more days)</div><div>=C2=A0 Expose to editor (with addit=
ional properties; description, edit type, etc)</div><div>=C2=A0 Serialise (=
load/save game)</div>
<div>=C2=A0 Replay serialisation (a different kind of serialisation that wo=
rks with different data sets)</div><div><br></div><div>And others I&#39;ve =
encountered in passing that I can&#39;t recall right now.</div><div><br></d=
iv>
<div>As you can imagine, any attempt to &#39;work around&#39; the lack of a=
n attribute system, ie, (ab)using enums, etc as have been suggested, leads =
to a big mess in the context of all these requirements.</div><div>Managemen=
t of such lists of stuff in disconnected places in code is time consuming,=
=C2=A0thoroughly annoying,=C2=A0error-prone, difficult to maintain, and lea=
ves programmers with the bitter taste of C++.</div>
<div>Alternatively, wrapping virtually every single declaration made in mix=
in() and declaring everything as strings is even more nasty, and the contra=
st between mixin() declarations and &#39;normal&#39; declarations looks com=
pletely stupid. (Totally unreadable + difficult to understand, breaks intel=
lisense, code completion, syntax hilighting, etc... ie, unusable)</div>
<div><br></div><div>Does anyone have a *realistic* suggestion for emulating=
 custom attributes? Something that doesn&#39;t have any(/many) of the side =
effects I mention?</div><div>I haven&#39;t come up with anything that&#39;s=
 acceptable yet.</div>
<div><br></div><div>If not, I assert that D absolutely needs a custom attri=
bute system. For us here, this will enable D the single biggest advantage o=
ver using C++ in the same context that I&#39;ve identified so far.</div>
<div>D&#39;s meta-programming is amazing, but sadly, proving pointless to m=
e right now without being able to mark stuff appropriately. All the meta ma=
gic is hovering just out of my grasp, due to the fact I have no way to indi=
cate what items should involve with what systems.</div>
<div>Currently, I have to maintain big registry tables of junk that must be=
 amended/updated any time anyone adds/changes anything... and I&#39;m feeli=
ng rather embarrassed when I tell the other non-D programmers that they jus=
t need to update this table here... and here... and make sure that&#39;s in=
 sync too before their stuff will just &#39;magically&#39; work ;)</div>
<div><br></div><div>C# and Java both have attributes, following these estab=
lished design patterns, I don&#39;t think there should be any mystery over =
how they should be implemented.</div>

--20cf30050ec00e08e504bced48c1--
Apr 05 2012
next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Manu,

as a workaround would marker interfaces help to solve your problem for =
the time being?

This is just a suggestion for the time being, as I agree with you, =
attributes/annotations are quite handy.

--
Paulo

"Manu" <turkeyman gmail.com> wrote in message =
news:mailman.1363.1333627256.4860.digitalmars-d puremagic.com...
I just want to add more real-world experience to the controversy.
I'm finding myself needing to use custom attributes almost every day.=20

I have numerous systems that need to scan the module for things marked =
accordingly to automate bindings to their respective systems.

This is my current list of attributes I want to mark things with:
  Export to game engine
  Export to script language
  Import from game engine
  ** Import from script language (tentative, I'm sure I'll need it in a =
few more days)
  Expose to editor (with additional properties; description, edit type, =
etc)
  Serialise (load/save game)
  Replay serialisation (a different kind of serialisation that works =
with different data sets)

And others I've encountered in passing that I can't recall right now.

As you can imagine, any attempt to 'work around' the lack of an =
attribute system, ie, (ab)using enums, etc as have been suggested, leads =
to a big mess in the context of all these requirements.
Management of such lists of stuff in disconnected places in code is time =
consuming, thoroughly annoying, error-prone, difficult to maintain, and =
leaves programmers with the bitter taste of C++.
Alternatively, wrapping virtually every single declaration made in =
mixin() and declaring everything as strings is even more nasty, and the =
contrast between mixin() declarations and 'normal' declarations looks =
completely stupid. (Totally unreadable + difficult to understand, breaks =
intellisense, code completion, syntax hilighting, etc... ie, unusable)

Does anyone have a *realistic* suggestion for emulating custom =
attributes? Something that doesn't have any(/many) of the side effects I =
mention?
I haven't come up with anything that's acceptable yet.

If not, I assert that D absolutely needs a custom attribute system. For =
us here, this will enable D the single biggest advantage over using C++ =
in the same context that I've identified so far.
D's meta-programming is amazing, but sadly, proving pointless to me =
right now without being able to mark stuff appropriately. All the meta =
magic is hovering just out of my grasp, due to the fact I have no way to =
indicate what items should involve with what systems.
Currently, I have to maintain big registry tables of junk that must be =
amended/updated any time anyone adds/changes anything... and I'm feeling =
rather embarrassed when I tell the other non-D programmers that they =
just need to update this table here... and here... and make sure that's =
in sync too before their stuff will just 'magically' work ;)

C# and Java both have attributes, following these established design =
patterns, I don't think there should be any mystery over how they should =
be implemented.
Apr 05 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--00248c711a116f4ff204bcedb8bf
Content-Type: text/plain; charset=UTF-8

On 5 April 2012 15:04, Paulo Pinto <pjmlp progtools.org> wrote:

   as a workaround would marker interfaces help to solve your problem for
 the time being?

I don't think it'd suit my purposes implemented as an interface for a variety of reasons: I need to be able to attribute many different types of things; data members, static functions, methods, etc. I need to be able to annotate 'loose' things at module scope. The whole point of the system is that it doesn't enforce a rigid interface. From my examples above, these items could be basically anything, anywhere. --00248c711a116f4ff204bcedb8bf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 5 April 2012 15:04, Paulo Pinto <span dir=3D"= ltr">&lt;<a href=3D"mailto:pjmlp progtools.org">pjmlp progtools.org</a>&gt;= </span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .= 8ex;border-left:1px #ccc solid;padding-left:1ex"> <div dir=3D"ltr"> <div dir=3D"ltr"> <div style=3D"font-size:12pt;font-family:&#39;Calibri&#39;"> <div><span style=3D"font-size:12pt">as a workaround would marker interfaces= help to solve your problem for the=20 time being?</span></div></div></div></div></blockquote><div><br></div><div>= I don&#39;t think it&#39;d suit my purposes implemented as an interface for= a variety of reasons:</div><div>=C2=A0 I need to be able to attribute many= different types of things; data members, static functions, methods, etc.</= div> <div>=C2=A0 I need to be able to annotate &#39;loose&#39; things at module = scope.</div><div>=C2=A0 The whole point of the system is that it doesn&#39;= t enforce a rigid interface. From my examples above, these items could be b= asically anything, anywhere.</div> </div> --00248c711a116f4ff204bcedb8bf--
Apr 05 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Paulo Pinto:

 C# and Java both have attributes, following these established 
 design patterns, I don't think there should be any mystery over 
 how they should be implemented.

There are other interesting ways to conceive attributes. I think of them in a different way, more like user-defined ways to extend the static type system. Bye, bearophile
Apr 05 2012
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/5/2012 5:00 AM, Manu wrote:
 C# and Java both have attributes, following these established design patterns,
I
 don't think there should be any mystery over how they should be implemented.

At the Lang.NEXT conference over the last 3 days, I was able to talk to many smart people about attributes. But I did find some confusion - are they best attached to the variable/function (i.e. "storage class"), or attached to the type ("type constructor")? I think the former. Attaching it to the type leads to all sorts of semantic issues. From your list of uses, it looks like attaching it to the variable or function is an apropos solution.
Apr 05 2012
next sibling parent reply deadalnix <deadalnix gmail.com> writes:
Le 05/04/2012 19:35, Walter Bright a écrit :
 On 4/5/2012 5:00 AM, Manu wrote:
 C# and Java both have attributes, following these established design
 patterns, I
 don't think there should be any mystery over how they should be
 implemented.

At the Lang.NEXT conference over the last 3 days, I was able to talk to many smart people about attributes. But I did find some confusion - are they best attached to the variable/function (i.e. "storage class"), or attached to the type ("type constructor")? I think the former. Attaching it to the type leads to all sorts of semantic issues. From your list of uses, it looks like attaching it to the variable or function is an apropos solution.

They should be attached to declarations.
Apr 05 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/5/12 12:44 PM, deadalnix wrote:
 Le 05/04/2012 19:35, Walter Bright a écrit :
 On 4/5/2012 5:00 AM, Manu wrote:
 C# and Java both have attributes, following these established design
 patterns, I
 don't think there should be any mystery over how they should be
 implemented.

At the Lang.NEXT conference over the last 3 days, I was able to talk to many smart people about attributes. But I did find some confusion - are they best attached to the variable/function (i.e. "storage class"), or attached to the type ("type constructor")? I think the former. Attaching it to the type leads to all sorts of semantic issues. From your list of uses, it looks like attaching it to the variable or function is an apropos solution.

They should be attached to declarations.

The question was whether the declaration affects the type of the declared or not. Andrei
Apr 05 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 04/05/2012 08:05 PM, Andrei Alexandrescu wrote:
 On 4/5/12 12:44 PM, deadalnix wrote:
 Le 05/04/2012 19:35, Walter Bright a écrit :
 On 4/5/2012 5:00 AM, Manu wrote:
 C# and Java both have attributes, following these established design
 patterns, I
 don't think there should be any mystery over how they should be
 implemented.

At the Lang.NEXT conference over the last 3 days, I was able to talk to many smart people about attributes. But I did find some confusion - are they best attached to the variable/function (i.e. "storage class"), or attached to the type ("type constructor")? I think the former. Attaching it to the type leads to all sorts of semantic issues. From your list of uses, it looks like attaching it to the variable or function is an apropos solution.

They should be attached to declarations.

The question was whether the declaration affects the type of the declared or not. Andrei

Ideally it would be powerful enough to allow changing the type, but most applications probably want the type to stay the same.
Apr 05 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/5/2012 11:32 AM, Timon Gehr wrote:
 Ideally it would be powerful enough to allow changing the type, but most
 applications probably want the type to stay the same.

Having it perturb the type implies a huge swamp of how that affects the semantics. You've got overloading, name mangling, type inference, implicit conversions, covariance, etc. All I can say is I see no way that can work with user defined semantics.
Apr 05 2012
parent deadalnix <deadalnix gmail.com> writes:
Le 05/04/2012 20:51, Walter Bright a écrit :
 On 4/5/2012 11:32 AM, Timon Gehr wrote:
 Ideally it would be powerful enough to allow changing the type, but most
 applications probably want the type to stay the same.

Having it perturb the type implies a huge swamp of how that affects the semantics. You've got overloading, name mangling, type inference, implicit conversions, covariance, etc. All I can say is I see no way that can work with user defined semantics.

I did some hacking into dmd in that regard, and I can confirm this is pretty hard. The problem is already quite hard, but the lack of separation of concerns into dmd's ast make things even harder. I'm afraid we have to delay anything that do codeception in a first shot, which is really sad because this is promising. I still think this is somewhere we have to go at some point, but we will have to wait.
Apr 05 2012
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-04-05 19:35, Walter Bright wrote:
 On 4/5/2012 5:00 AM, Manu wrote:
 C# and Java both have attributes, following these established design
 patterns, I
 don't think there should be any mystery over how they should be
 implemented.

At the Lang.NEXT conference over the last 3 days, I was able to talk to many smart people about attributes. But I did find some confusion - are they best attached to the variable/function (i.e. "storage class"), or attached to the type ("type constructor")? I think the former. Attaching it to the type leads to all sorts of semantic issues. From your list of uses, it looks like attaching it to the variable or function is an apropos solution.

If I recall correctly, both Java annotations and C# attributes let you specify with a fine grained control on what the attributes are attached to. foo FooBar bar () {} For example, is " foo" attached to "FooBar" or "bar". Java uses the Target annotation to specify this. -- /Jacob Carlborg
Apr 05 2012
next sibling parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 05-04-2012 22:06, Jacob Carlborg wrote:
 On 2012-04-05 19:35, Walter Bright wrote:
 On 4/5/2012 5:00 AM, Manu wrote:
 C# and Java both have attributes, following these established design
 patterns, I
 don't think there should be any mystery over how they should be
 implemented.

At the Lang.NEXT conference over the last 3 days, I was able to talk to many smart people about attributes. But I did find some confusion - are they best attached to the variable/function (i.e. "storage class"), or attached to the type ("type constructor")? I think the former. Attaching it to the type leads to all sorts of semantic issues. From your list of uses, it looks like attaching it to the variable or function is an apropos solution.

If I recall correctly, both Java annotations and C# attributes let you specify with a fine grained control on what the attributes are attached to. foo FooBar bar () {} For example, is " foo" attached to "FooBar" or "bar". Java uses the Target annotation to specify this.

C#'s grammar directly encodes what metadata element the attribute is attached to. How feasible this is with D's rather... loose attribute/modifier parsing, I don't know. -- - Alex
Apr 05 2012
prev sibling parent deadalnix <deadalnix gmail.com> writes:
Le 05/04/2012 22:06, Jacob Carlborg a écrit :
 On 2012-04-05 19:35, Walter Bright wrote:
 On 4/5/2012 5:00 AM, Manu wrote:
 C# and Java both have attributes, following these established design
 patterns, I
 don't think there should be any mystery over how they should be
 implemented.

At the Lang.NEXT conference over the last 3 days, I was able to talk to many smart people about attributes. But I did find some confusion - are they best attached to the variable/function (i.e. "storage class"), or attached to the type ("type constructor")? I think the former. Attaching it to the type leads to all sorts of semantic issues. From your list of uses, it looks like attaching it to the variable or function is an apropos solution.

If I recall correctly, both Java annotations and C# attributes let you specify with a fine grained control on what the attributes are attached to. foo FooBar bar () {} For example, is " foo" attached to "FooBar" or "bar". Java uses the Target annotation to specify this.

This is bar's declaration.
Apr 05 2012
prev sibling next sibling parent reply Ary Manzana <ary esperanto.org.ar> writes:
On 4/6/12 1:35 AM, Walter Bright wrote:
 On 4/5/2012 5:00 AM, Manu wrote:
 C# and Java both have attributes, following these established design
 patterns, I
 don't think there should be any mystery over how they should be
 implemented.

At the Lang.NEXT conference over the last 3 days, I was able to talk to many smart people about attributes. But I did find some confusion - are they best attached to the variable/function (i.e. "storage class"), or attached to the type ("type constructor")? I think the former. Attaching it to the type leads to all sorts of semantic issues.

I don't understand the difference between "storage class" and "type constructor". I guess I do. But my answer is the same as deadalnix: they are attached to declarations (at compile time). Can you give us an example of the confusion that arose? I can't understand it without examples. I think it should work like this: custom class Foo { custom void bar() { } void baz() { } } class Other {} __traits(hasAttribute, Foo, 'custom') --> true __traits(hasAttribute, Other, 'custom') --> false // I have no idea how to iterate the members of Foo, or get a reference to the "bar" method... I can't understand what __traits(getMember) returns from the docs...
Apr 05 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-04-06 05:30, Ary Manzana wrote:

 I don't understand the difference between "storage class" and "type
 constructor". I guess I do. But my answer is the same as deadalnix: they
 are attached to declarations (at compile time).

 Can you give us an example of the confusion that arose? I can't
 understand it without examples.

 I think it should work like this:

  custom
 class Foo {

   custom
 void bar() { }

 void baz() { }
 }

 class Other {}

 __traits(hasAttribute, Foo, 'custom') --> true
 __traits(hasAttribute, Other, 'custom') --> false

 // I have no idea how to iterate the members of Foo, or get a reference
 to the "bar" method... I can't understand what __traits(getMember)
 returns from the docs...

I would like to have the possibility to attach attributes to types and parameters as well. Some think like this: class Bar { not_null(Foo) bar ( custom int a) {} } Where not_null is attached to "Foo" and custom is attached to "a". -- /Jacob Carlborg
Apr 06 2012
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 04/06/2012 02:23 PM, Jacob Carlborg wrote:
 I would like to have the possibility to attach attributes to types and
 parameters as well. Some think like this:

 class Bar
 {
  not_null(Foo) bar ( custom int a) {}
 }

 Where  not_null is attached to "Foo" and  custom is attached to "a".

not_null cannot be attached to "Foo". It would have to create a new symbol not_null(Foo). And then, all the concerns Walter has raised apply.
Apr 06 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-04-06 14:31, Timon Gehr wrote:

  not_null cannot be attached to "Foo". It would have to create a new
 symbol  not_null(Foo). And then, all the concerns Walter has raised apply.

Hmm, I guess. But it would be nice to have :) -- /Jacob Carlborg
Apr 06 2012
prev sibling next sibling parent reply Piotr Szturmaj <bncrbme jadamspam.pl> writes:
Jacob Carlborg wrote:
 I would like to have the possibility to attach attributes to types and
 parameters as well. Some think like this:

 class Bar
 {
  not_null(Foo) bar ( custom int a) {}
 }

 Where  not_null is attached to "Foo" and  custom is attached to "a".

Do you mean return type? I think your syntax has some serious disadvantages. Consider parameters and multiple attributes. For return types I'd like to see something like this: return: not_null return: MyAttr("foo") Foo bar( custom int a) {} This is similar to C#'s [return: MyAttr]. Alternatively it might be: return(not_null) return(MyAttr("foo"))
Apr 06 2012
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-04-06 14:38, Piotr Szturmaj wrote:

 Do you mean return type? I think your syntax has some serious
 disadvantages. Consider parameters and multiple attributes.

 For return types I'd like to see something like this:

  return: not_null
  return: MyAttr("foo")
 Foo bar( custom int a) {}

 This is similar to C#'s [return: MyAttr]. Alternatively it might be:

  return(not_null)
  return(MyAttr("foo"))

Hmm, or something like how Java does it. You attached this information when you declare the attribute: Retention(RetentionPolicy.RUNTIME) // Make this annotation accessible at runtime via reflection. Target({ElementType.METHOD}) // This annotation can only be applied to class methods. public interface Tweezable { } Or with another syntax: attribute target(type) struct not_null {} -- /Jacob Carlborg
Apr 06 2012
parent Piotr Szturmaj <bncrbme jadamspam.pl> writes:
Jacob Carlborg wrote:
 On 2012-04-06 14:38, Piotr Szturmaj wrote:

 Do you mean return type? I think your syntax has some serious
 disadvantages. Consider parameters and multiple attributes.

 For return types I'd like to see something like this:

  return: not_null
  return: MyAttr("foo")
 Foo bar( custom int a) {}

 This is similar to C#'s [return: MyAttr]. Alternatively it might be:

  return(not_null)
  return(MyAttr("foo"))

Hmm, or something like how Java does it. You attached this information when you declare the attribute: Retention(RetentionPolicy.RUNTIME) // Make this annotation accessible at runtime via reflection. Target({ElementType.METHOD}) // This annotation can only be applied to class methods. public interface Tweezable { } Or with another syntax: attribute target(type) struct not_null {}

I think that target is a solution for simple types, but UDTs may use another one: struct MyAttr { template Attach(Symbol) { static if (!is(typeof(Symbol) == class) || !is(typeof(Symbol) : A)) static assert(0, "MyAttr must be attached to classes derived from class A"); } } This allows more complex target checking possible. Besides above example, some attributes can be mutually exclusive and __traits(hasAttribute, ...) may be used to check that.
Apr 06 2012
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-04-06 14:55, Manu wrote:
 On 6 April 2012 15:38, Piotr Szturmaj <bncrbme jadamspam.pl
 <mailto:bncrbme jadamspam.pl>> wrote:

     Jacob Carlborg wrote:

         I would like to have the possibility to attach attributes to
         types and
         parameters as well. Some think like this:

         class Bar
         {
          not_null(Foo) bar ( custom int a) {}
         }

         Where  not_null is attached to "Foo" and  custom is attached to "a".


     Do you mean return type? I think your syntax has some serious
     disadvantages. Consider parameters and multiple attributes.

     For return types I'd like to see something like this:

      return: not_null
      return: MyAttr("foo")
     Foo bar( custom int a) {}

     This is similar to C#'s [return: MyAttr]. Alternatively it might be:

      return(not_null)
      return(MyAttr("foo"))


 There's no need to attribute a return value. A) I think you're confusing
 it with attributing *types* again, and B) you can just attribute the
 function its self, and have access to precisely the same information.
 You can't attribute a return value, since attributes aren't transferred
 along with assignments, they are bound to their respective declaration.

It depends on what we want out of attributes. -- /Jacob Carlborg
Apr 06 2012
prev sibling parent Piotr Szturmaj <bncrbme jadamspam.pl> writes:
Manu wrote:
 On 6 April 2012 15:38, Piotr Szturmaj <bncrbme jadamspam.pl
     For return types I'd like to see something like this:

      return: not_null
      return: MyAttr("foo")
     Foo bar( custom int a) {}

     This is similar to C#'s [return: MyAttr]. Alternatively it might be:

      return(not_null)
      return(MyAttr("foo"))


 There's no need to attribute a return value. A) I think you're confusing
 it with attributing *types* again, and B) you can just attribute the
 function its self, and have access to precisely the same information.
 You can't attribute a return value, since attributes aren't transferred
 along with assignments, they are bound to their respective declaration.

See http://msdn.microsoft.com/en-us/library/b3787ac0%28v=vs.80%29.aspx Attributes on return values are useful for RPC methods. For example: with attribute, one can specify how return value is serialized/marshalled. In C#, attributes can be specified on function, parameters and return type _simultaneously_. I don't think we should limit D ones to functions and parameters.
Apr 06 2012
prev sibling parent deadalnix <deadalnix gmail.com> writes:
Le 06/04/2012 14:23, Jacob Carlborg a écrit :
 On 2012-04-06 05:30, Ary Manzana wrote:

 I don't understand the difference between "storage class" and "type
 constructor". I guess I do. But my answer is the same as deadalnix: they
 are attached to declarations (at compile time).

 Can you give us an example of the confusion that arose? I can't
 understand it without examples.

 I think it should work like this:

  custom
 class Foo {

   custom
 void bar() { }

 void baz() { }
 }

 class Other {}

 __traits(hasAttribute, Foo, 'custom') --> true
 __traits(hasAttribute, Other, 'custom') --> false

 // I have no idea how to iterate the members of Foo, or get a reference
 to the "bar" method... I can't understand what __traits(getMember)
 returns from the docs...

I would like to have the possibility to attach attributes to types and parameters as well. Some think like this: class Bar { not_null(Foo) bar ( custom int a) {} } Where not_null is attached to "Foo" and custom is attached to "a".

As foo isn't a declaration, I don't think it is attribute we want here. Or an extension, because it have a lot of consequences.
Apr 06 2012
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 04/06/2012 11:57 AM, Manu wrote:
 I don't think it should affect the type, although this shows a
 conceptual problem when referring to existing attributes via the same
 terminology. Obviously one might consider 'const', 'pure', etc
 attributes themselves, and they clearly do affect the type.
 Perhaps that's the key distinction between an ' '
 attribute(/'annotation'?), and a no-' ' attribute?

safe affects the type.
Apr 06 2012
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 05 Apr 2012 14:05:49 -0400, Andrei Alexandrescu  =

<SeeWebsiteForEmail erdani.org> wrote:

 On 4/5/12 12:44 PM, deadalnix wrote:
 Le 05/04/2012 19:35, Walter Bright a =C3=A9crit :
 On 4/5/2012 5:00 AM, Manu wrote:
 C# and Java both have attributes, following these established desig=




 patterns, I
 don't think there should be any mystery over how they should be
 implemented.

At the Lang.NEXT conference over the last 3 days, I was able to talk=



 many smart people about attributes. But I did find some confusion - =



 they best attached to the variable/function (i.e. "storage class"), =



 attached to the type ("type constructor")? I think the former.  =



 Attaching
 it to the type leads to all sorts of semantic issues.

 From your list of uses, it looks like attaching it to the variable o=



 function is an apropos solution.

They should be attached to declarations.

The question was whether the declaration affects the type of the =

 declared or not.

For user-defined attributes, no. This is metadata for the programmer/li= b = to decode. Obviously, compiler-defined attributes can. -Steve
Apr 05 2012
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-04-05 14:00, Manu wrote:
 I just want to add more real-world experience to the controversy.
 I'm finding myself needing to use custom attributes almost every day.

 I have numerous systems that need to scan the module for things marked
 accordingly to automate bindings to their respective systems.

Yes, give us custom attributes now :) -- /Jacob Carlborg
Apr 05 2012
parent Mike Parker <aldacron gmail.com> writes:
On 4/6/2012 4:43 AM, Jacob Carlborg wrote:
 On 2012-04-05 14:00, Manu wrote:
 I just want to add more real-world experience to the controversy.
 I'm finding myself needing to use custom attributes almost every day.

 I have numerous systems that need to scan the module for things marked
 accordingly to automate bindings to their respective systems.

Yes, give us custom attributes now :)

Apr 05 2012
prev sibling next sibling parent "Kapps" <opantm2+spam gmail.com> writes:
On Thursday, 5 April 2012 at 17:36:31 UTC, Walter Bright wrote:
 On 4/5/2012 5:00 AM, Manu wrote:
 C# and Java both have attributes, following these established 
 design patterns, I
 don't think there should be any mystery over how they should 
 be implemented.

At the Lang.NEXT conference over the last 3 days, I was able to talk to many smart people about attributes. But I did find some confusion - are they best attached to the variable/function (i.e. "storage class"), or attached to the type ("type constructor")? I think the former. Attaching it to the type leads to all sorts of semantic issues. From your list of uses, it looks like attaching it to the variable or function is an apropos solution.

I'm not sure if I'm understanding this correctly, but by attaching to the type do you mean altering the type of the declaration such as shared or const do? If so, I am completely against attributes being able to do this; there's already better ways such as a struct with alias this. Another issue is that if runtime reflection gets added, it would be nice to be able to add attributes at runtime. This could cause things to break if the type itself is changed instead of getting attached to the declaration. Plus, attributes should not be invasive, they're just notes. The two main situations where I see attributes being used are: 1) Add some information about a declaration, such as NotSerialized on a field. 2) Add some information to a type, such as Serializable. If this can be done, with being able to pass compile-time value(s) to the attribute, all situations I have ever desired/seen/used attributes for would work nicely.
Apr 05 2012
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/5/2012 5:00 AM, Manu wrote:
 C# and Java both have attributes, following these established design patterns,
I
 don't think there should be any mystery over how they should be implemented.

I was thinking of something along the lines of what has been proposed here earlier: attr(identifier = expression) as a storage class, like: attr(foo = bar + 1) int x; and then: __traits(hasAttribute, x, foo) would return true, and: __traits(getAttribute, x, foo) would return the expression (bar+1). The expression would be compile-time only, evaluated at the point of declaration. The implementation is simple enough, just attach to each symbol an array of (identifier,expression) pairs. You could also omit the expression, and just have: attr(bar) int y;
Apr 05 2012
next sibling parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 06-04-2012 08:47, Walter Bright wrote:
 On 4/5/2012 5:00 AM, Manu wrote:
  > C# and Java both have attributes, following these established design
 patterns, I
  > don't think there should be any mystery over how they should be
 implemented.

 I was thinking of something along the lines of what has been proposed
 here earlier:

  attr(identifier = expression)

 as a storage class, like:

  attr(foo = bar + 1) int x;

 and then:

 __traits(hasAttribute, x, foo)

 would return true, and:

 __traits(getAttribute, x, foo)

 would return the expression (bar+1). The expression would be
 compile-time only, evaluated at the point of declaration.

 The implementation is simple enough, just attach to each symbol an array
 of (identifier,expression) pairs.

 You could also omit the expression, and just have:

  attr(bar) int y;

I think this is mostly reasonable. I assume that it would be possible to use the comma operator to attach multiple values to it? I.e.: attr(foo = bar, baz) int x; My only other concern is what Kapps pointed out about larger projects and overlapping attribute names. -- - Alex
Apr 06 2012
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/6/2012 12:17 AM, Kapps wrote:
 I like it for the most part. One thing I'd like to see is placing multiple
 attributes both by using multiple  attr()'s, and by using comma separated
 identifier/expression pairs inside a single  attr. In other words, the
following
 two declarations would be identical.

  attr(Description = "Blah", ReadOnly)
 int ID;

  attr(Description = "Blah")
  attr(ReadOnly)
 int ID;

Yes, that makes sense.
 My only concerns:

 First,  attr() is a little verbose / not exactly pretty. This isn't really a
big
 issue, since attributes aren't exactly piled on and it makes it easy to tell
 what's going on. It is a little uglier than in other languages however.

Could do: [[name = value]] I suppose. Not sure what's better.
 Secondly, from what I can tell it's an arbitrary key value combo. What would
 happen if you're working on a larger project and two unrelated libraries try to
 use the same attribute name to mean different things? With the module system
 this issue doesn't exist since you have to import it and can
 selectively/privately do so, but from what I understand the method you're
 proposing doesn't declare the attribute itself at all. Am I just
 misunderstanding this part?

Good question. I don't have experience using attributes, so I don't know if this would be a problem. Keep in mind that the attribute lookup will only be done for a particular symbol, there won't be any global lookup.
Apr 06 2012
next sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 06-04-2012 09:32, Walter Bright wrote:
 On 4/6/2012 12:17 AM, Kapps wrote:
 I like it for the most part. One thing I'd like to see is placing
 multiple
 attributes both by using multiple  attr()'s, and by using comma separated
 identifier/expression pairs inside a single  attr. In other words, the
 following
 two declarations would be identical.

  attr(Description = "Blah", ReadOnly)
 int ID;

  attr(Description = "Blah")
  attr(ReadOnly)
 int ID;

Yes, that makes sense.
 My only concerns:

 First,  attr() is a little verbose / not exactly pretty. This isn't
 really a big
 issue, since attributes aren't exactly piled on and it makes it easy
 to tell
 what's going on. It is a little uglier than in other languages however.

Could do: [[name = value]] I suppose. Not sure what's better.
 Secondly, from what I can tell it's an arbitrary key value combo. What
 would
 happen if you're working on a larger project and two unrelated
 libraries try to
 use the same attribute name to mean different things? With the module
 system
 this issue doesn't exist since you have to import it and can
 selectively/privately do so, but from what I understand the method you're
 proposing doesn't declare the attribute itself at all. Am I just
 misunderstanding this part?

Good question. I don't have experience using attributes, so I don't know if this would be a problem. Keep in mind that the attribute lookup will only be done for a particular symbol, there won't be any global lookup.

It actually can be a problem. In .NET land, there are many attributes across many projects (and even in the framework itself) with the same names. It turns out that regular namespace lookup rules alleviate this problem. -- - Alex
Apr 06 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/6/2012 12:35 AM, Alex Rønne Petersen wrote:
 It actually can be a problem. In .NET land, there are many attributes across
 many projects (and even in the framework itself) with the same names. It turns
 out that regular namespace lookup rules alleviate this problem.

Perhaps a better scheme is: enum foo = 3; ... attr(foo) int x; That way, foo will follow all the usual rules.
Apr 06 2012
next sibling parent reply Ary Manzana <ary esperanto.org.ar> writes:
On 4/6/12 3:48 PM, Walter Bright wrote:
 On 4/6/2012 12:35 AM, Alex Rønne Petersen wrote:
 It actually can be a problem. In .NET land, there are many attributes
 across
 many projects (and even in the framework itself) with the same names.
 It turns
 out that regular namespace lookup rules alleviate this problem.

Perhaps a better scheme is: enum foo = 3; ... attr(foo) int x; That way, foo will follow all the usual rules.

At least in .Net and Java it's something like this. 1. You declare your attributes. This is something good, because you have a place to say "This attribute is used for marking fields as non-serializable". The syntax in Java for declaring an attribute: public interface Foo { String xxx; int yyy; } In D maybe interface could be used to (in order to avoid introducing another keyword... or maybe use attribute instead): attribute Foo { string xxx; int yyy; } 2. You use them by using their names. What you are proposing if for attribute foo to be attr(foo). But in Java it's foo. So in Java you would use that attribute like this: Foo(xxx = "hello", yyy = 1); void func() {} Then you can get the "Foo" attribute in func, and ask for it's xxx and yyy. --- Now, your proposal is much simpler and it will become inconvenient in some cases. For example suppose you want to provide attributes for serialization (I guess the classic example). With your proposal it would be: /// This is actually an attribute. Use this together with serialized_name. enum serialize = 1; enum serialized_name = 2; attr(serialize = true, serialized_name = "Foo") int x; Now, with the way things are done in Java and C#: /// Marks a field to be serialized. attribute serialize { /// The name to be used. /// If not specified, the name of the member will be used instead. string name; } serialize(name = "Foo") int x; You can see the syntax is much cleaner. The attribute declaration also serves as documentation and to group attributes related to the serialization process. Now, to implement this is not very much difficult than what you proposed. 1. Introduce the syntax to define attributes. Piece of cake, since it's much more or less the syntax of a struct, but functions or nested types are not allowed. Parse them into an AttributeDecl or something like that. 2. When the compiler finds attr(field = value) it uses normal lookup rules to find "attr". Then it checks it's an attributes. Then all fields are check in turn to see if their type match. You can probably put there anything that's compile-time evaluatable, though usually primitive types and strings are enough. If a field is not specified, it's type.init will be used. 3. The syntax for querying is almost the same as you proposed: __traits(hasAttribute, x, serializable) // true __traits(getAttribtue, x, serializable, name) // "Foo" 4. Declare the core attributes in object.di or similar: safe, nothrow, etc. You can also document them. 5. Probably deprecate __traits(isSafe) and so on, since hasAttribute can be used for that.
Apr 06 2012
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/6/2012 2:50 AM, Ary Manzana wrote:
 The syntax in Java for declaring an attribute:

 public  interface Foo {
 String xxx;
 int yyy;
 }

 In D maybe  interface could be used to (in order to avoid introducing another
 keyword... or maybe use  attribute instead):

  attribute Foo {
 string xxx;
 int yyy;
 }

I don't see the need for creating a new kind of symbol.
 2. You use them by using their names. What you are proposing if for attribute
 foo to be  attr(foo). But in Java it's  foo.

 So in Java you would use that attribute like this:

  Foo(xxx = "hello", yyy = 1);
 void func() {}

 Then you can get the "Foo" attribute in func, and ask for it's xxx and yyy.

This is a runtime system.
 Now, your proposal is much simpler and it will become inconvenient in some
 cases. For example suppose you want to provide attributes for serialization (I
 guess the classic example). With your proposal it would be:

 /// This is actually an attribute. Use this together with serialized_name.
 enum serialize = 1;
 enum serialized_name = 2;

  attr(serialize = true, serialized_name = "Foo")
 int x;

No, it would be: enum serialize = true; enum serialize_name = "Foo"; attr(serialize, serialized_name) int x; There would be no initialization in the attr syntax.
 Now, with the way things are done in Java and C#:

 /// Marks a field to be serialized.
  attribute serialize {
 /// The name to be used.
 /// If not specified, the name of the member will be used instead.
 string name;
 }

  serialize(name = "Foo")
 int x;

 You can see the syntax is much cleaner. The attribute declaration also serves
as
 documentation and to group attributes related to the serialization process.

I don't see that it is cleaner - there's no particular reason why a new symbol type needs to be introduced.
 Now, to implement this is not very much difficult than what you proposed.

 1. Introduce the syntax to define attributes. Piece of cake, since it's much
 more or less the syntax of a struct, but functions or nested types are not
 allowed. Parse them into an AttributeDecl or something like that.
 2. When the compiler finds  attr(field = value) it uses normal lookup rules to
 find "attr". Then it checks it's an attributes. Then all fields are check in
 turn to see if their type match. You can probably put there anything that's
 compile-time evaluatable, though usually primitive types and strings are
enough.
 If a field is not specified, it's type.init will be used.
 3. The syntax for querying is almost the same as you proposed:

 __traits(hasAttribute, x, serializable) // true
 __traits(getAttribtue, x, serializable, name) // "Foo"

 4. Declare the core attributes in object.di or similar:  safe,  nothrow, etc.
 You can also document them.
 5. Probably deprecate __traits(isSafe) and so on, since hasAttribute can be
used
 for that.

safe, nothrow, etc., require a lot of semantic support in the compiler. They cannot pretend to be user defined attributes.
Apr 06 2012
next sibling parent reply Ary Manzana <ary esperanto.org.ar> writes:
On 4/6/12 6:12 PM, Walter Bright wrote:
 On 4/6/2012 2:50 AM, Ary Manzana wrote:
 The syntax in Java for declaring an attribute:

 public  interface Foo {
 String xxx;
 int yyy;
 }

 In D maybe  interface could be used to (in order to avoid introducing
 another
 keyword... or maybe use  attribute instead):

  attribute Foo {
 string xxx;
 int yyy;
 }

I don't see the need for creating a new kind of symbol.
 2. You use them by using their names. What you are proposing if for
 attribute
 foo to be  attr(foo). But in Java it's  foo.

 So in Java you would use that attribute like this:

  Foo(xxx = "hello", yyy = 1);
 void func() {}

 Then you can get the "Foo" attribute in func, and ask for it's xxx and
 yyy.

This is a runtime system.

Yes, but I'm thinking about a compile-time system (as I showed in the example usages below).
 Now, your proposal is much simpler and it will become inconvenient in
 some
 cases. For example suppose you want to provide attributes for
 serialization (I
 guess the classic example). With your proposal it would be:

 /// This is actually an attribute. Use this together with
 serialized_name.
 enum serialize = 1;
 enum serialized_name = 2;

  attr(serialize = true, serialized_name = "Foo")
 int x;

No, it would be: enum serialize = true; enum serialize_name = "Foo"; attr(serialize, serialized_name) int x; There would be no initialization in the attr syntax.

Hmmm... I didn't get that quite well. You are using the symbol's name as the attribute name? In my example I missed splitting it into two files: my_attributes.d: attribute serialize { } my_usage_of_it.d: import my_attributes; serialize(...)
 Now, with the way things are done in Java and C#:

 /// Marks a field to be serialized.
  attribute serialize {
 /// The name to be used.
 /// If not specified, the name of the member will be used instead.
 string name;
 }

  serialize(name = "Foo")
 int x;

 You can see the syntax is much cleaner. The attribute declaration also
 serves as
 documentation and to group attributes related to the serialization
 process.

I don't see that it is cleaner - there's no particular reason why a new symbol type needs to be introduced.
 Now, to implement this is not very much difficult than what you proposed.

 1. Introduce the syntax to define attributes. Piece of cake, since
 it's much
 more or less the syntax of a struct, but functions or nested types are
 not
 allowed. Parse them into an AttributeDecl or something like that.
 2. When the compiler finds  attr(field = value) it uses normal lookup
 rules to
 find "attr". Then it checks it's an attributes. Then all fields are
 check in
 turn to see if their type match. You can probably put there anything
 that's
 compile-time evaluatable, though usually primitive types and strings
 are enough.
 If a field is not specified, it's type.init will be used.
 3. The syntax for querying is almost the same as you proposed:

 __traits(hasAttribute, x, serializable) // true
 __traits(getAttribtue, x, serializable, name) // "Foo"

 4. Declare the core attributes in object.di or similar:  safe,
  nothrow, etc.
 You can also document them.
 5. Probably deprecate __traits(isSafe) and so on, since hasAttribute
 can be used
 for that.

safe, nothrow, etc., require a lot of semantic support in the compiler. They cannot pretend to be user defined attributes.

Yes they can. That's how it is done in C# and Java. In fact, IUnknown is pretending to be an interface and has semantic support in the compiler.
Apr 06 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/6/2012 3:27 AM, Ary Manzana wrote:
  safe,  nothrow, etc., require a lot of semantic support in the
 compiler. They cannot pretend to be user defined attributes.

Yes they can. That's how it is done in C# and Java. In fact, IUnknown is pretending to be an interface and has semantic support in the compiler.

All the semantics of safe are in the compiler. None of it can be user defined. There's just no point to trying to make it user defined. It's like trying to make int user defined. IUnknown's semantics are nearly all user-defined.
Apr 06 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 04/06/2012 12:53 PM, Walter Bright wrote:
 On 4/6/2012 3:27 AM, Ary Manzana wrote:
  safe,  nothrow, etc., require a lot of semantic support in the
 compiler. They cannot pretend to be user defined attributes.

Yes they can. That's how it is done in C# and Java. In fact, IUnknown is pretending to be an interface and has semantic support in the compiler.

All the semantics of safe are in the compiler. None of it can be user defined. There's just no point to trying to make it user defined. It's like trying to make int user defined. IUnknown's semantics are nearly all user-defined.

The proposal is not to make the semantics of safe user defined. I think he proposes to make 'safe' a symbol that is looked up like an user defined symbol. Some languages do the same for the built-in integer type.
Apr 06 2012
parent Ary Manzana <ary esperanto.org.ar> writes:
On 4/6/12 7:09 PM, Timon Gehr wrote:
 On 04/06/2012 12:53 PM, Walter Bright wrote:
 On 4/6/2012 3:27 AM, Ary Manzana wrote:
  safe,  nothrow, etc., require a lot of semantic support in the
 compiler. They cannot pretend to be user defined attributes.

Yes they can. That's how it is done in C# and Java. In fact, IUnknown is pretending to be an interface and has semantic support in the compiler.

All the semantics of safe are in the compiler. None of it can be user defined. There's just no point to trying to make it user defined. It's like trying to make int user defined. IUnknown's semantics are nearly all user-defined.

The proposal is not to make the semantics of safe user defined. I think he proposes to make 'safe' a symbol that is looked up like an user defined symbol. Some languages do the same for the built-in integer type.

The compiler does the same for TypeInfo, TypeInfo_ClassDeclaration or what ever, Object, etc. I'm just proposing safe to be seen as a user-defined attribute, but implemented in the compiler with special semantic. I'm saying it so that lookup rules become easier: just search. No special cases like "if the attribute name is safe". Of course, treat the special cases later inside the compiler code.
Apr 06 2012
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 04/06/2012 12:12 PM, Walter Bright wrote:
 On 4/6/2012 2:50 AM, Ary Manzana wrote:
 The syntax in Java for declaring an attribute:

 public  interface Foo {
 String xxx;
 int yyy;
 }

 In D maybe  interface could be used to (in order to avoid introducing
 another
 keyword... or maybe use  attribute instead):

  attribute Foo {
 string xxx;
 int yyy;
 }

I don't see the need for creating a new kind of symbol.

It would behave like a struct anyway. The issue is whether any struct should be allowed to be used as an attribute, or whether a runtime instance of an attribute can be created. Syntax could just as well be this: attribute struct Foo { // ... }
 2. You use them by using their names. What you are proposing if for
 attribute
 foo to be  attr(foo). But in Java it's  foo.

 So in Java you would use that attribute like this:

  Foo(xxx = "hello", yyy = 1);
 void func() {}

 Then you can get the "Foo" attribute in func, and ask for it's xxx and
 yyy.

This is a runtime system.

In Java, yes. But the general scheme works well even at compile time. It is possible to evaluate struct constructors at compile time. enum Foo attr = __traits(getAttribute, func, Foo);
 Now, your proposal is much simpler and it will become inconvenient in
 some
 cases. For example suppose you want to provide attributes for
 serialization (I
 guess the classic example). With your proposal it would be:

 /// This is actually an attribute. Use this together with
 serialized_name.
 enum serialize = 1;
 enum serialized_name = 2;

  attr(serialize = true, serialized_name = "Foo")
 int x;

No, it would be: enum serialize = true; enum serialize_name = "Foo"; attr(serialize, serialized_name) int x;

I don't see how that would work. Do you propose to define attributes based on the mapping of the name of random manifest constants to their value? That would be a kludgy hack.
 There would be no initialization in the  attr syntax.

 Now, with the way things are done in Java and C#:

 /// Marks a field to be serialized.
  attribute serialize {
 /// The name to be used.
 /// If not specified, the name of the member will be used instead.
 string name;
 }

  serialize(name = "Foo")
 int x;

 You can see the syntax is much cleaner. The attribute declaration also
 serves as
 documentation and to group attributes related to the serialization
 process.

I don't see that it is cleaner

I think it is cleaner on a conceptual level, even if the syntax was attr(serialize("Foo"))
 - there's no particular reason why a new
 symbol type needs to be introduced.

There is not strictly a need for a _new_ symbol type, but attribute lookup should definitely be symbol based and not string/value based. Why would there be any benefit in bypassing the module system for user defined attributes?
Apr 06 2012
parent Ary Manzana <ary esperanto.org.ar> writes:
On 4/6/12 6:29 PM, Timon Gehr wrote:
 On 04/06/2012 12:12 PM, Walter Bright wrote:
 On 4/6/2012 2:50 AM, Ary Manzana wrote:
 The syntax in Java for declaring an attribute:

 public  interface Foo {
 String xxx;
 int yyy;
 }

 In D maybe  interface could be used to (in order to avoid introducing
 another
 keyword... or maybe use  attribute instead):

  attribute Foo {
 string xxx;
 int yyy;
 }

I don't see the need for creating a new kind of symbol.

It would behave like a struct anyway. The issue is whether any struct should be allowed to be used as an attribute, or whether a runtime instance of an attribute can be created. Syntax could just as well be this: attribute struct Foo { // ... }

True, I struct can be fine. And I don't see any problem in using it in runtime. Though I'm sure nobody would like it to remain in the obj file if it's only used at compile time...
Apr 06 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-04-06 12:12, Walter Bright wrote:

 I don't see the need for creating a new kind of symbol.

If you create a new symbol, i.e. "Foo" then it would obey the normal look up rules.
 This is a runtime system.

Says who? It doesn't need to be in D.
 I don't see that it is cleaner - there's no particular reason why a new
 symbol type needs to be introduced.

For attributes with a single value this syntax sugar can be allowed (and is in Java): serialize("Foo") int x; I think that is clean. -- /Jacob Carlborg
Apr 06 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-04-06 11:50, Ary Manzana wrote:
 On 4/6/12 3:48 PM, Walter Bright wrote:
 On 4/6/2012 12:35 AM, Alex Rønne Petersen wrote:
 It actually can be a problem. In .NET land, there are many attributes
 across
 many projects (and even in the framework itself) with the same names.
 It turns
 out that regular namespace lookup rules alleviate this problem.

Perhaps a better scheme is: enum foo = 3; ... attr(foo) int x; That way, foo will follow all the usual rules.

At least in .Net and Java it's something like this. 1. You declare your attributes. This is something good, because you have a place to say "This attribute is used for marking fields as non-serializable".

This is much better, as I've said before. -- /Jacob Carlborg
Apr 06 2012
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/6/2012 2:41 AM, Johannes Pfau wrote:
 The last time custom attributes where discussed, a C# like model was
 proposed. Is there a good reason why we should deviate from the C#
 implementation?

C# uses a runtime implementation, not a compile time one.
Apr 06 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/6/12 5:06 AM, Walter Bright wrote:
 On 4/6/2012 2:41 AM, Johannes Pfau wrote:
 The last time custom attributes where discussed, a C# like model was
 proposed. Is there a good reason why we should deviate from the C#
 implementation?

C# uses a runtime implementation, not a compile time one.

Speaking of the distinction, it would be great if we arranged things such that attributes are a lowering to existing D (i.e. the compiler rewrites a nice attribute syntax into clunky D code you wouldn't want to write by hand). Lowerings have worked miracles for us in terms of keeping language semantics simple and reducing implementation bugs. We should use them wherever appropriate. Andrei
Apr 06 2012
next sibling parent deadalnix <deadalnix gmail.com> writes:
Le 06/04/2012 17:00, Andrei Alexandrescu a écrit :
 On 4/6/12 5:06 AM, Walter Bright wrote:
 On 4/6/2012 2:41 AM, Johannes Pfau wrote:
 The last time custom attributes where discussed, a C# like model was
 proposed. Is there a good reason why we should deviate from the C#
 implementation?

C# uses a runtime implementation, not a compile time one.

Speaking of the distinction, it would be great if we arranged things such that attributes are a lowering to existing D (i.e. the compiler rewrites a nice attribute syntax into clunky D code you wouldn't want to write by hand). Lowerings have worked miracles for us in terms of keeping language semantics simple and reducing implementation bugs. We should use them wherever appropriate. Andrei

Again, I rise the need of AOP. No need for runtime attribute or compiler magic if we have AOP that could interleave « clunky D code you wouldn't want to write by hand » without adding yet again another language feature.
Apr 06 2012
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 04/06/2012 05:00 PM, Andrei Alexandrescu wrote:
 On 4/6/12 5:06 AM, Walter Bright wrote:
 On 4/6/2012 2:41 AM, Johannes Pfau wrote:
 The last time custom attributes where discussed, a C# like model was
 proposed. Is there a good reason why we should deviate from the C#
 implementation?

C# uses a runtime implementation, not a compile time one.

Speaking of the distinction, it would be great if we arranged things such that attributes are a lowering to existing D (i.e. the compiler rewrites a nice attribute syntax into clunky D code you wouldn't want to write by hand).

What would that look like?
 Lowerings have worked miracles for us in terms of keeping language
 semantics simple and reducing implementation bugs.

What do you have in mind here? All lowerings I am aware of are trivial ones and their implementation resulted in sloppy error handling (eg: foreach) for no clear benefit. Some of them (eg: with statement) have even made the implementation bug situation worse.
 We should use them
 wherever appropriate.


 Andrei

I don't think they are in this case. What will help reducing implementation bugs is that most of their implementation is already covered by the CTFE implementation.
Apr 06 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/6/12 10:09 AM, Timon Gehr wrote:
 Speaking of the distinction, it would be great if we arranged things
 such that attributes are a lowering to existing D (i.e. the compiler
 rewrites a nice attribute syntax into clunky D code you wouldn't want to
 write by hand).

What would that look like?

Essentially we want to associate with any symbol (be it a type, function, method, or whatnot) some extra information in the form of a tuple of key/value pairs. The value can be anything CTFE. How would one do that "by hand", albeit ugly and verbose? Once we get the desired functionality, we work back on a syntax for it. And we're done.
 Lowerings have worked miracles for us in terms of keeping language
 semantics simple and reducing implementation bugs.

What do you have in mind here?

All: foreach, scope, operator overloading - wherever we used lowerings it's been an unqualified success. I am only sorry we didn't use them more often and more systematically.
 All lowerings I am aware of are trivial ones and their implementation
 resulted in sloppy error handling (eg: foreach) for no clear benefit.

Defining foreach as a lowering clarifies to both the library author and the user what the expectations are.
 Some of them (eg: with statement) have even made the implementation bug
 situation worse.

"with" is not implemented via a lowering. Andrei
Apr 06 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 04/06/2012 09:15 PM, Andrei Alexandrescu wrote:
 On 4/6/12 10:09 AM, Timon Gehr wrote:
 Speaking of the distinction, it would be great if we arranged things
 such that attributes are a lowering to existing D (i.e. the compiler
 rewrites a nice attribute syntax into clunky D code you wouldn't want to
 write by hand).

What would that look like?

Essentially we want to associate with any symbol (be it a type, function, method, or whatnot) some extra information in the form of a tuple of key/value pairs. The value can be anything CTFE. How would one do that "by hand", albeit ugly and verbose? Once we get the desired functionality, we work back on a syntax for it. And we're done.

There is no existing in-language solution whose only bad property is its ugliness, because it cannot be allowed to introduce additional symbols.
 Lowerings have worked miracles for us in terms of keeping language
 semantics simple and reducing implementation bugs.

What do you have in mind here?

All: foreach, scope, operator overloading - wherever we used lowerings it's been an unqualified success. I am only sorry we didn't use them more often and more systematically.

I think they have been applied where they were appropriate. What other existing language features would you rather have specified as a lowering?
 All lowerings I am aware of are trivial ones and their implementation
 resulted in sloppy error handling (eg: foreach) for no clear benefit.

Defining foreach as a lowering clarifies to both the library author and the user what the expectations are.

Agreed, using lowering custom overloading of language constructs is good. These usages have slipped my mind because they are so different from what we are discussing here. I was thinking about foreach over built in arrays. For example: foreach(double i,x; (int[]).init){} Error: cannot implicitly convert expression (i) of type double to ulong i.e. using lowering for implementation without any additional checks is not a good thing. Anyway, how does the argument apply to the custom attribute case? The specification of how custom attributes work is certainly simpler and more clear than the specification of how the 'code that is too ugly to be written by hand' is generated and getting it right should be comparably difficult for both. The solution that uses a lowering would need additional compiler support for hiding additionally generated symbols. This makes the lowering even harder to follow for someone who wants to get started on custom attributes. It just seems kludgy to me.
Apr 06 2012
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/6/12 2:47 PM, Timon Gehr wrote:
 There is no existing in-language solution whose only bad property is its
 ugliness, because it cannot be allowed to introduce additional symbols.

You can always assume fresh variables even though indeed there's no support for them. Just use __ as prefix and then combine with a cookie and the existing symbol name. There will be no clashes.
 All: foreach, scope, operator overloading - wherever we used lowerings
 it's been an unqualified success. I am only sorry we didn't use them
 more often and more systematically.


I forgot the new lambda syntax ("=>") was defined as a lowering and as a consequence is came virtually bug free.
 I think they have been applied where they were appropriate. What other
 existing language features would you rather have specified as a lowering?

Some array and associative array literals and operations. All object copying.
 Anyway, how does the argument apply to the custom attribute case? The
 specification of how custom attributes work is certainly simpler and
 more clear than the specification of how the 'code that is too ugly to
 be written by hand' is generated and getting it right should be
 comparably difficult for both. The solution that uses a lowering would
 need additional compiler support for hiding additionally generated
 symbols. This makes the lowering even harder to follow for someone who
 wants to get started on custom attributes. It just seems kludgy to me.

Expressing attributes in terms of what they do within attribute-less D is crucial to keeping both definition and implementation simple. Hidden symbols are a non-issue. Andrei
Apr 06 2012
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/6/2012 3:23 AM, Manu wrote:
 What about:

 struct editor
 {
    this(string name, EditType, Colour = Colour.Default, string description =
null)
    {
      //...
    }

    blah blah blah
 }

  attr(editor("thing",...blah...))

Are you really changing the arguments for every declaration? Or is it one set that is repeated everywhere?
 I don't see the advantage over:
  editor(...)

 ?

Name collisions with other attributes.
Apr 06 2012
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 04/06/2012 12:28 PM, Walter Bright wrote:
 On 4/6/2012 3:23 AM, Manu wrote:
 What about:

 struct editor
 {
 this(string name, EditType, Colour = Colour.Default, string
 description = null)
 {
 //...
 }

 blah blah blah
 }

  attr(editor("thing",...blah...))

Are you really changing the arguments for every declaration? Or is it one set that is repeated everywhere?

Yes, allowing the arguments to be different is a crucial feature. Custom attributes are not a boolean thing, that is just the case for built-in ones. They are arbitrary data that is attached to a declaration and can then be used to build powerful semantics using compile time reflection.
 I don't see the advantage over:
  editor(...)

 ?

Name collisions with other attributes.

Which other attributes? Built-in ones? Otherwise, the D module system will be great at disambiguating the collisions as soon as inaccessible private symbols do not participate in symbol name collisions any more. Maybe we could just keep all the lower case attributes reserved in order to be future proof.
Apr 06 2012
prev sibling next sibling parent reply Piotr Szturmaj <bncrbme jadamspam.pl> writes:
Walter Bright wrote:
 Are you really changing the arguments for every declaration? Or is it
 one set that is repeated everywhere?

The former.
 I don't see the advantage over:
  editor(...)

 ?

Name collisions with other attributes.

The same applies to other identifiers, like class named "class". NET has predefined attributes too, but they use the same syntax as the custom ones: [MyAttr(5)] int x; I think MyAttr(5) declaration looks more readable than attr(MyAttr(5)). To avoid name clashes, in case of using builtin name, qualified identifier should be used: myModule.pure pure void fn() {}
Apr 06 2012
parent Piotr Szturmaj <bncrbme jadamspam.pl> writes:
Piotr Szturmaj wrote:
  myModule.pure
  pure
 void fn() {}

should be: myModule.safe safe void fn() {}
Apr 06 2012
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-04-06 12:28, Walter Bright wrote:

 Name collisions with other   attributes.

Just as we have today with keywords and symbols, I don't see the problem. -- /Jacob Carlborg
Apr 06 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-04-06 15:48, Adam D. Ruppe wrote:
 On Friday, 6 April 2012 at 12:52:27 UTC, Jacob Carlborg wrote:
 Just as we have today with keywords and symbols, I don't see the problem.

Things like safe aren't keywords though. They are just magic identifiers. Think of the implementation: switch(tok.ident) { case Id::safe: case Id::property: // etc for built ins default: // handle user ones here } If you were to define a struct safe {}, which is perfectly legal D, and try to use it, you won't get what you expect. It will trigger the case safe before it goes to the default. So, the user defined one will just be quietly hidden.

I mean that "int" is a keyword and "int" is in the same "scope" as the rest of the symbols. So if we allow custom attributes, like " foo", it's the same "problem" as with regular identifiers. Regular identifiers can conflict with keywords. -- /Jacob Carlborg
Apr 07 2012
prev sibling parent deadalnix <deadalnix gmail.com> writes:
Le 06/04/2012 12:28, Walter Bright a écrit :
 On 4/6/2012 3:23 AM, Manu wrote:
 What about:

 struct editor
 {
 this(string name, EditType, Colour = Colour.Default, string
 description = null)
 {
 //...
 }

 blah blah blah
 }

  attr(editor("thing",...blah...))

Are you really changing the arguments for every declaration? Or is it one set that is repeated everywhere?
 I don't see the advantage over:
  editor(...)

 ?

Name collisions with other attributes.

That isn't a good argument IMO. We have type int and user defined types. I cannot do struct int {}. Same for safe or property or any other language defined property.
Apr 06 2012
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 04/06/2012 11:41 AM, Johannes Pfau wrote:
 Syntax in D would be different of course, but I see absolutely no need
 for the redundant (and ugly)  attr.

 Declaring a custom attribute:
 ---------
 module std.something;

 struct Author
 {
      string name;
      public this(string name)
      {
          this.name = name;
      }
 }
 ---------

 Using it:
 ---------
 import std.something; //Usual namespace lookup rules apply to attributes

 /*
   *  Author(param) calls the constructor of the Author struct and
   * attaches the struct instance to test. Probably  Author (without
   * parenthesis) coud be made to mean std.something.Author.init
   */
  Author("Johannes Pfau") int test;
 ---------

 Attaching attributes multiple times as in C# should be possible.

 Using reflection to get that attribute:
 ---------
 if(__traits(hasAttribute, test, std.something.Author))
 {
      Author[] authors = __traits(getAttribute, test,
          std.something.Author);
 }
 ---------

 An array is used here to support attaching the same attribute multiple
 times. Of course "auto authors = ..." should be usable here too.

This all seems very reasonable. I think this is how things should work. (maybe syntax will need to be different, because Walter does not seem to like the idea of un-reserving identifier.)
Apr 06 2012
prev sibling next sibling parent deadalnix <deadalnix gmail.com> writes:
Le 06/04/2012 11:41, Johannes Pfau a écrit :
 Am Fri, 06 Apr 2012 00:48:34 -0700
 schrieb Walter Bright<newshound2 digitalmars.com>:

 On 4/6/2012 12:35 AM, Alex Rønne Petersen wrote:
 It actually can be a problem. In .NET land, there are many
 attributes across many projects (and even in the framework itself)
 with the same names. It turns out that regular namespace lookup
 rules alleviate this problem.

Perhaps a better scheme is: enum foo = 3; ... attr(foo) int x; That way, foo will follow all the usual rules.

The last time custom attributes where discussed, a C# like model was proposed. Is there a good reason why we should deviate from the C# implementation? C#: http://msdn.microsoft.com/en-US/library/48zeb25s(v=vs.80).aspx http://msdn.microsoft.com/en-US/library/sw480ze8(v=vs.100).aspx http://msdn.microsoft.com/en-US/library/z919e8tw(v=vs.80).aspx (C# attributes can be applied to almost everything, therefore sometimes "disambiguating targets" is necessary. Probably not needed in D): http://msdn.microsoft.com/en-US/library/b3787ac0(v=vs.80).aspx Syntax in D would be different of course, but I see absolutely no need for the redundant (and ugly) attr. Declaring a custom attribute: --------- module std.something; struct Author { string name; public this(string name) { this.name = name; } } --------- Using it: --------- import std.something; //Usual namespace lookup rules apply to attributes /* * Author(param) calls the constructor of the Author struct and * attaches the struct instance to test. Probably Author (without * parenthesis) coud be made to mean std.something.Author.init */ Author("Johannes Pfau") int test; --------- Attaching attributes multiple times as in C# should be possible. Using reflection to get that attribute: --------- if(__traits(hasAttribute, test, std.something.Author)) { Author[] authors = __traits(getAttribute, test, std.something.Author); } --------- An array is used here to support attaching the same attribute multiple times. Of course "auto authors = ..." should be usable here too.

That is a really nice proposal !
Apr 06 2012
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-04-06 09:48, Walter Bright wrote:
 On 4/6/2012 12:35 AM, Alex Rønne Petersen wrote:
 It actually can be a problem. In .NET land, there are many attributes
 across
 many projects (and even in the framework itself) with the same names.
 It turns
 out that regular namespace lookup rules alleviate this problem.

Perhaps a better scheme is: enum foo = 3; ... attr(foo) int x; That way, foo will follow all the usual rules.

What would "3" do in this case? Be the value of the attribute? -- /Jacob Carlborg
Apr 06 2012
prev sibling parent deadalnix <deadalnix gmail.com> writes:
Le 06/04/2012 12:23, Manu a écrit :
 On 6 April 2012 10:48, Walter Bright <newshound2 digitalmars.com
 <mailto:newshound2 digitalmars.com>> wrote:

     On 4/6/2012 12:35 AM, Alex Rønne Petersen wrote:

         It actually can be a problem. In .NET land, there are many
         attributes across
         many projects (and even in the framework itself) with the same
         names. It turns
         out that regular namespace lookup rules alleviate this problem.



     Perhaps a better scheme is:

        enum foo = 3;

        ...

         attr(foo) int x;

     That way, foo will follow all the usual rules.


 What about:

 struct editor
 {
    this(string name, EditType, Colour = Colour.Default, string
 description = null)
    {
      //...
    }

    blah blah blah
 }

  attr(editor("thing",...blah...))

 I don't see the advantage over:
  editor(...)

 ?

+1 I see no additional benefit for this. D have very good lookup rules for looking symbols into modules, so let's use them.
Apr 06 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-04-06 09:32, Walter Bright wrote:
 Could do:

 [[name = value]]

 I suppose. Not sure what's better.

No. See my other reply. -- /Jacob Carlborg
Apr 06 2012
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/6/2012 12:31 AM, Bernard Helyer wrote:
 I like it. Perhaps

  attr(bar)

 could be equivalent to

  attr(bar = true)

 so you don't get any weird failure state for __traits(getAttribute?

That's what the hasAttribute is for.
Apr 06 2012
prev sibling next sibling parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 06-04-2012 09:31, Bernard Helyer wrote:
 On Friday, 6 April 2012 at 06:47:56 UTC, Walter Bright wrote:
 On 4/5/2012 5:00 AM, Manu wrote:
 C# and Java both have attributes, following these established

 don't think there should be any mystery over how they should

I was thinking of something along the lines of what has been proposed here earlier: attr(identifier = expression) as a storage class, like: attr(foo = bar + 1) int x; and then: __traits(hasAttribute, x, foo) would return true, and: __traits(getAttribute, x, foo) would return the expression (bar+1). The expression would be compile-time only, evaluated at the point of declaration. The implementation is simple enough, just attach to each symbol an array of (identifier,expression) pairs. You could also omit the expression, and just have: attr(bar) int y;

I like it. Perhaps attr(bar) could be equivalent to attr(bar = true) so you don't get any weird failure state for __traits(getAttribute?

While I understand the rationale, that seems a bit too "magic"... -- - Alex
Apr 06 2012
prev sibling next sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 06-04-2012 08:47, Walter Bright wrote:
 On 4/5/2012 5:00 AM, Manu wrote:
  > C# and Java both have attributes, following these established design
 patterns, I
  > don't think there should be any mystery over how they should be
 implemented.

 I was thinking of something along the lines of what has been proposed
 here earlier:

  attr(identifier = expression)

 as a storage class, like:

  attr(foo = bar + 1) int x;

 and then:

 __traits(hasAttribute, x, foo)

 would return true, and:

 __traits(getAttribute, x, foo)

 would return the expression (bar+1). The expression would be
 compile-time only, evaluated at the point of declaration.

 The implementation is simple enough, just attach to each symbol an array
 of (identifier,expression) pairs.

 You could also omit the expression, and just have:

  attr(bar) int y;

Also, by storage class do you mean it will work only on fields? Attributes are very useful on many different kinds of declarations, so if that's the case, I think that would be too limiting. -- - Alex
Apr 06 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/6/2012 12:42 AM, Alex Rønne Petersen wrote:
 Also, by storage class do you mean it will work only on fields?

No. Storage classes work on fields, functions, and variables.
Apr 06 2012
next sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 06-04-2012 09:47, Walter Bright wrote:
 On 4/6/2012 12:42 AM, Alex Rønne Petersen wrote:
 Also, by storage class do you mean it will work only on fields?

No. Storage classes work on fields, functions, and variables.

What about type declarations? I think those ought to be supported too. E.g. it makes sense to mark an entire type as attr(serializable) (or the inverse). -- - Alex
Apr 06 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/6/2012 12:49 AM, Alex Rønne Petersen wrote:
 What about type declarations? I think those ought to be supported too. E.g. it
 makes sense to mark an entire type as  attr(serializable) (or the inverse).

That would make it a "type constructor", not a storage class, which we talked about earlier in the thread. I refer you to that discussion.
Apr 06 2012
next sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 06-04-2012 09:54, Walter Bright wrote:
 On 4/6/2012 12:49 AM, Alex Rønne Petersen wrote:
 What about type declarations? I think those ought to be supported too.
 E.g. it
 makes sense to mark an entire type as  attr(serializable) (or the
 inverse).

That would make it a "type constructor", not a storage class, which we talked about earlier in the thread. I refer you to that discussion.

To be clear, I don't want annotations on a type declaration to actually affect the type. Annotations are just that: Annotations. Nothing else. Does a design like that still give rise to the semantic issues you mentioned (it isn't clear what those are)? -- - Alex
Apr 06 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/6/2012 1:15 AM, Alex Rønne Petersen wrote:
 On 06-04-2012 09:54, Walter Bright wrote:
 On 4/6/2012 12:49 AM, Alex Rønne Petersen wrote:
 What about type declarations? I think those ought to be supported too.
 E.g. it
 makes sense to mark an entire type as  attr(serializable) (or the
 inverse).

That would make it a "type constructor", not a storage class, which we talked about earlier in the thread. I refer you to that discussion.

To be clear, I don't want annotations on a type declaration to actually affect the type. Annotations are just that: Annotations. Nothing else.

What would an annotation on a type mean if it does not affect the type? Would it just be baggage carried along? If so, how would that affect types inside of a template, where the type was passed as a type constructor? How would type inference work? Would an alias carry or drop the baggage? How would overloading work? How would covariance work? It's a maze of complex decisions.
 Does a design like that still give rise to the semantic issues you mentioned
(it
 isn't clear what those are)?

Yes. (I know Java does this. But Java has a trivial type system compared with D. It doesn't even have type aliases. It doesn't have type constructors. Etc.)
Apr 06 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 04/06/2012 12:16 PM, Walter Bright wrote:
 On 4/6/2012 1:15 AM, Alex Rønne Petersen wrote:
 On 06-04-2012 09:54, Walter Bright wrote:
 On 4/6/2012 12:49 AM, Alex Rønne Petersen wrote:
 What about type declarations? I think those ought to be supported too.
 E.g. it
 makes sense to mark an entire type as  attr(serializable) (or the
 inverse).

That would make it a "type constructor", not a storage class, which we talked about earlier in the thread. I refer you to that discussion.

To be clear, I don't want annotations on a type declaration to actually affect the type. Annotations are just that: Annotations. Nothing else.

What would an annotation on a type mean if it does not affect the type?

I don't get that either, it has to affect the type. It does not have any effects on the semantics of instances on the type though. Name mangling can stay the same though.
 Would it just be baggage carried along?

Yes.
 If so, how would that affect types inside of a template, where the type was
passed as a type
 constructor?

How do you pass a type as a type constructor?
 How would type inference work?

Just as it does now.
 Would an alias carry or drop the baggage?

Carry. An alias does not change the referenced symbol.
 How would overloading work?
 How would covariance work?

As they do now. Custom attributes don't have semantic meaning recognised by the compiler. They are just data.
 It's a maze of complex decisions.

I think you can add a list of annotations to the class in the AST that represents a declaration (the common superclass of all declarations) and everything will just work.
 Does a design like that still give rise to the semantic issues you
 mentioned (it
 isn't clear what those are)?

Yes. (I know Java does this. But Java has a trivial type system compared with D. It doesn't even have type aliases. It doesn't have type constructors. Etc.)

I think there is some sort of communication problem, because the feature that is being requested is quite simple. It would probably be valuable if you could point out the issues you see in detail (using example code.)
Apr 06 2012
prev sibling next sibling parent reply Ary Manzana <ary esperanto.org.ar> writes:
On 4/6/12 3:54 PM, Walter Bright wrote:
 On 4/6/2012 12:49 AM, Alex Rønne Petersen wrote:
 What about type declarations? I think those ought to be supported too.
 E.g. it
 makes sense to mark an entire type as  attr(serializable) (or the
 inverse).

That would make it a "type constructor", not a storage class, which we talked about earlier in the thread. I refer you to that discussion.

What's the difference between "type constructor" and "storage class" beside the name?
Apr 06 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/6/2012 2:18 AM, Ary Manzana wrote:
 On 4/6/12 3:54 PM, Walter Bright wrote:
 On 4/6/2012 12:49 AM, Alex Rønne Petersen wrote:
 What about type declarations? I think those ought to be supported too.
 E.g. it
 makes sense to mark an entire type as  attr(serializable) (or the
 inverse).

That would make it a "type constructor", not a storage class, which we talked about earlier in the thread. I refer you to that discussion.

What's the difference between "type constructor" and "storage class" beside the name?

static const(int)* foo; static is a storage class. const is a type constructor. There is no type 'static'.
Apr 06 2012
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 04/06/2012 12:17 PM, Walter Bright wrote:
 On 4/6/2012 2:18 AM, Ary Manzana wrote:
 On 4/6/12 3:54 PM, Walter Bright wrote:
 On 4/6/2012 12:49 AM, Alex Rønne Petersen wrote:
 What about type declarations? I think those ought to be supported too.
 E.g. it
 makes sense to mark an entire type as  attr(serializable) (or the
 inverse).

That would make it a "type constructor", not a storage class, which we talked about earlier in the thread. I refer you to that discussion.

What's the difference between "type constructor" and "storage class" beside the name?

static const(int)* foo; static is a storage class. const is a type constructor. There is no type 'static'.

Still, the 'static' in static struct S{ // ... } Affects S. Correct?
Apr 06 2012
prev sibling parent deadalnix <deadalnix gmail.com> writes:
Le 06/04/2012 12:17, Walter Bright a écrit :
 On 4/6/2012 2:18 AM, Ary Manzana wrote:
 On 4/6/12 3:54 PM, Walter Bright wrote:
 On 4/6/2012 12:49 AM, Alex Rønne Petersen wrote:
 What about type declarations? I think those ought to be supported too.
 E.g. it
 makes sense to mark an entire type as  attr(serializable) (or the
 inverse).

That would make it a "type constructor", not a storage class, which we talked about earlier in the thread. I refer you to that discussion.

What's the difference between "type constructor" and "storage class" beside the name?

static const(int)* foo; static is a storage class. const is a type constructor. There is no type 'static'.

Why can't attribute be attached on declaration ? By the way, this whole qualify the type or something is a big misfeature. annotation should be attached to the declared stuff. attr Bar foo() { return Bar(); } is qualifying « foo ». Qualifying bar make no sense whatsoever.
Apr 06 2012
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 04/06/2012 09:54 AM, Walter Bright wrote:
 On 4/6/2012 12:49 AM, Alex Rønne Petersen wrote:
 What about type declarations? I think those ought to be supported too.
 E.g. it
 makes sense to mark an entire type as  attr(serializable) (or the
 inverse).

That would make it a "type constructor", not a storage class, which we talked about earlier in the thread. I refer you to that discussion.

I think what was discussed there is that attr(foo) int x; Wouldn't change the type of x. attr(foo) struct Foo{} Should add additional information to the type Foo. I don't see any issues with it, and not supporting it would be very strange.
Apr 06 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/6/2012 2:54 AM, Timon Gehr wrote:
 Should add additional information to the type Foo. I don't see any issues with
 it, and not supporting it would be very strange.

How would: attr(foo) int x; int y; work? Are x and y the same type or not? Now, consider: auto c = b ? x : y; What type does c have? int or attr(foo)int ? And that's really just the beginning. How about: struct S(T) { T t; } Instantiate it with S!int and S!( attr(foo)int). Are those the same instantiation, or different? If the same, does S.t have the attribute or not? And, whatever you choose for the semantics, what is the sensible, intuitive rule for it?
Apr 06 2012
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 04/06/2012 12:23 PM, Walter Bright wrote:
 On 4/6/2012 2:54 AM, Timon Gehr wrote:
 Should add additional information to the type Foo. I don't see any
 issues with
 it, and not supporting it would be very strange.

How would: attr(foo) int x; int y; work? Are x and y the same type or not?

Yes, they are. (But a future extension might leave this choice up to 'foo')
 Now, consider:

 auto c = b ? x : y;

 What type does c have? int or  attr(foo)int ? And that's really just the
 beginning. How about:

 struct S(T) {
 T t;
 }

 Instantiate it with S!int and S!( attr(foo)int). Are those the same
 instantiation, or different? If the same, does S.t have the attribute or
 not?

There is no such thing as an attr(foo) int, because attr is not a type constructor.
 And, whatever you choose for the semantics, what is the sensible,
 intuitive rule for it?

Custom attributes apply to the symbol declaration. Because any symbol is declared just once, there is never any ambiguity. There is no conceptual gap between attr(foo) int x; and attr(bar) struct S{...} Obviously attr(bar) changes S, but there is only one declaration of S.
Apr 06 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/6/2012 3:49 AM, Timon Gehr wrote:
 On 04/06/2012 12:23 PM, Walter Bright wrote:
 On 4/6/2012 2:54 AM, Timon Gehr wrote:
 Should add additional information to the type Foo. I don't see any
 issues with
 it, and not supporting it would be very strange.

How would: attr(foo) int x; int y; work? Are x and y the same type or not?

Yes, they are. (But a future extension might leave this choice up to 'foo')
 Now, consider:

 auto c = b ? x : y;

 What type does c have? int or  attr(foo)int ? And that's really just the
 beginning. How about:

 struct S(T) {
 T t;
 }

 Instantiate it with S!int and S!( attr(foo)int). Are those the same
 instantiation, or different? If the same, does S.t have the attribute or
 not?

There is no such thing as an attr(foo) int, because attr is not a type constructor.

But you said it was added to the *type*.
Apr 09 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 04/10/2012 12:18 AM, Walter Bright wrote:
 On 4/6/2012 3:49 AM, Timon Gehr wrote:
 On 04/06/2012 12:23 PM, Walter Bright wrote:
 On 4/6/2012 2:54 AM, Timon Gehr wrote:
 Should add additional information to the type Foo. I don't see any
 issues with
 it, and not supporting it would be very strange.

How would: attr(foo) int x; int y; work? Are x and y the same type or not?

Yes, they are. (But a future extension might leave this choice up to 'foo')
 Now, consider:

 auto c = b ? x : y;

 What type does c have? int or  attr(foo)int ? And that's really just the
 beginning. How about:

 struct S(T) {
 T t;
 }

 Instantiate it with S!int and S!( attr(foo)int). Are those the same
 instantiation, or different? If the same, does S.t have the attribute or
 not?

There is no such thing as an attr(foo) int, because attr is not a type constructor.

But you said it was added to the *type*.

What I said was that it is added to the declaration. If the declaration happens to declare a type, then that must affect the type: attr(foo) struct Foo{} // annotate 'foo' attr(bar) Foo x; __traits(getAttributes, typeof(x)); // this will find 'foo', but no 'bar' __traits(getAttributes, x); // this will find 'bar', but not 'foo'
Apr 10 2012
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/6/2012 4:20 AM, Manu wrote:
     On 4/6/2012 2:54 AM, Timon Gehr wrote:
          Should add additional information to the type Foo.
 Attributes are on the declaration, and not passed around.

Right, they are not added to the *type*.
Apr 09 2012
parent deadalnix <deadalnix gmail.com> writes:
Le 10/04/2012 00:19, Walter Bright a écrit :
 On 4/6/2012 4:20 AM, Manu wrote:
 On 4/6/2012 2:54 AM, Timon Gehr wrote:
 Should add additional information to the type Foo.
 Attributes are on the declaration, and not passed around.

Right, they are not added to the *type*.

No, they are not, or it will become a crazy mess.
Apr 10 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-04-06 14:58, Steven Schveighoffer wrote:

 An annotation is simply metadata, stored in the compiler, and looked up
 via compiler directives. Optionally (and I would encourage this),
 TypeInfo would store annotations on type declarations for retrieval at
 runtime.

 -Steve

Yes, annotations/attributes should be accessible at both compile time and runtime. -- /Jacob Carlborg
Apr 06 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-04-06 09:47, Walter Bright wrote:
 On 4/6/2012 12:42 AM, Alex Rønne Petersen wrote:
 Also, by storage class do you mean it will work only on fields?

No. Storage classes work on fields, functions, and variables.

They need to be attachable to classes, structs, enums and so on as well. -- /Jacob Carlborg
Apr 06 2012
prev sibling next sibling parent Artur Skawina <art.08.09 gmail.com> writes:
On 04/06/12 11:18, Ary Manzana wrote:
 On 4/6/12 3:54 PM, Walter Bright wrote:
 On 4/6/2012 12:49 AM, Alex Rønne Petersen wrote:
 What about type declarations? I think those ought to be supported too.
 E.g. it
 makes sense to mark an entire type as  attr(serializable) (or the
 inverse).

That would make it a "type constructor", not a storage class, which we talked about earlier in the thread. I refer you to that discussion.

What's the difference between "type constructor" and "storage class" beside the name?

attr(deprecated) struct T { int blah; } // every instance of S now marked with it. struct S { int blah; } attr(deprecated) S si; // just si marked; think "static S si;" etc I actually don't like the proposed scheme - it's both way to verbose and not nearly sufficient. I have to leave soon and don't have the time to fully describe the problems, but just a few key points: - Both of the above should work; the "storage class" is the more important part. Wouldn't just having the type-attributes automatically propagate (as a default "storage class") to the instances, w/o affecting the type in any way, be enough? - If the above would work, then there has to be a way to remove an attribute from some instances. - Attributes needs to be declared in some way, otherwise a typo will go undetected and you may not notice it until it's too late. Think " attr(serialisable)" etc - Attributes need to be mergeable, ie you really don't want to mark a significant number of symbols as serializable, exported-to-X, exported-to-Y etc. Something like "alias attr("serializable", "export_X", "export_Y") new_attr"; attr(new_attr) int i;" might work. - At the very least "__traits(getAttribute, x, foo)" needs to be something like "__traits( attr, x, foo); even better would be "x. attr("foo");". - Should attributes be strings? That would avoid clashes with keywords. OTOH that would mean that attribute definitions needs to use different syntax than plain structs. Hmm, maybe that would be a good thing anyway. - Namespaces. There needs to be a system NS and a compiler-specific NS. So that you can do things like attr(__GNU, "flatten", "hot") instead of "pragma(GNU_attribute, flatten, hot)". - Null/empty attributes, ie "alias attr() new_attr;", should work; necessary eg when the compiler lacks support for certain features. There are probably many more issues, these are just the few obvious ones that immediately come to mind. artur
Apr 06 2012
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-04-06 09:17, Kapps wrote:

 Secondly, from what I can tell it's an arbitrary key value combo. What
 would happen if you're working on a larger project and two unrelated
 libraries try to use the same attribute name to mean different things?
 With the module system this issue doesn't exist since you have to import
 it and can selectively/privately do so, but from what I understand the
 method you're proposing doesn't declare the attribute itself at all. Am
 I just misunderstanding this part?

The way I'm thinking of attributes is that they are declared, somehow, in a module. Since it's declared in a module it would have the same rules any other declared symbol, with the possibility to use a fully qualified name. -- /Jacob Carlborg
Apr 06 2012
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-04-06 08:47, Walter Bright wrote:
 On 4/5/2012 5:00 AM, Manu wrote:
  > C# and Java both have attributes, following these established design
 patterns, I
  > don't think there should be any mystery over how they should be
 implemented.

 I was thinking of something along the lines of what has been proposed
 here earlier:

  attr(identifier = expression)

 as a storage class, like:

  attr(foo = bar + 1) int x;

 and then:

 __traits(hasAttribute, x, foo)

 would return true, and:

 __traits(getAttribute, x, foo)

 would return the expression (bar+1). The expression would be
 compile-time only, evaluated at the point of declaration.

 The implementation is simple enough, just attach to each symbol an array
 of (identifier,expression) pairs.

 You could also omit the expression, and just have:

  attr(bar) int y;

I'm not a particular fan of that syntax. I would go with: identifier(key = value/expression) Like: foo(k1 = bar + 1, k2 = bar + 2) int x; If the attribute takes one key-value pair: foo(value = bar + 1) int x; Can be shortened like: foo(bar + 1) int x; And for attributes that don't take any values: foo int x; -- /Jacob Carlborg
Apr 06 2012
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-04-06 08:47, Walter Bright wrote:
 On 4/5/2012 5:00 AM, Manu wrote:
  > C# and Java both have attributes, following these established design
 patterns, I
  > don't think there should be any mystery over how they should be
 implemented.

 I was thinking of something along the lines of what has been proposed
 here earlier:

  attr(identifier = expression)

 as a storage class, like:

  attr(foo = bar + 1) int x;

 and then:

 __traits(hasAttribute, x, foo)

 would return true, and:

 __traits(getAttribute, x, foo)

 would return the expression (bar+1). The expression would be
 compile-time only, evaluated at the point of declaration.

 The implementation is simple enough, just attach to each symbol an array
 of (identifier,expression) pairs.

 You could also omit the expression, and just have:

  attr(bar) int y;

Again, this is my proposal: http://www.digitalmars.com/d/archives/digitalmars/D/Proposal_user_defined_attributes_161624.html#N161742 -- /Jacob Carlborg
Apr 06 2012
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/6/12 1:47 AM, Walter Bright wrote:
 On 4/5/2012 5:00 AM, Manu wrote:
  > C# and Java both have attributes, following these established design
 patterns, I
  > don't think there should be any mystery over how they should be
 implemented.

 I was thinking of something along the lines of what has been proposed
 here earlier:

  attr(identifier = expression)

 as a storage class, like:

  attr(foo = bar + 1) int x;

 and then:

 __traits(hasAttribute, x, foo)

 would return true, and:

 __traits(getAttribute, x, foo)

 would return the expression (bar+1). The expression would be
 compile-time only, evaluated at the point of declaration.

You also need means to enumerate attributes. Andrei
Apr 06 2012
parent reply Piotr Szturmaj <bncrbme jadamspam.pl> writes:
Andrei Alexandrescu wrote:
 On 4/6/12 1:47 AM, Walter Bright wrote:
 __traits(hasAttribute, x, foo)

 would return true, and:

 __traits(getAttribute, x, foo)

 would return the expression (bar+1). The expression would be
 compile-time only, evaluated at the point of declaration.

You also need means to enumerate attributes.

Minimalistically getAttribute*s* should be enough: __traits(getAttributes, x) would return all attributes of x. The rest can be implemented as library templates in std.traits.
Apr 06 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-04-08 09:27, Marco Leise wrote:
 I don't want this thread to disappear. The ideas presented here have common
basic features among the nice-to-haves.

 For these to work it would require:
 - user annotations to functions/methods/structs/classes
 - only CTFE support (as annotations don't change at runtime)

I don't see why the attributes should be accessible at runtime. Even if they're read-only it's still good to be able to read the attributes at runtime. -- /Jacob Carlborg
Apr 08 2012
parent reply deadalnix <deadalnix gmail.com> writes:
Le 08/04/2012 12:44, Jacob Carlborg a écrit :
 On 2012-04-08 09:27, Marco Leise wrote:
 I don't want this thread to disappear. The ideas presented here have
 common basic features among the nice-to-haves.

 For these to work it would require:
 - user annotations to functions/methods/structs/classes
 - only CTFE support (as annotations don't change at runtime)

I don't see why the attributes should be accessible at runtime. Even if they're read-only it's still good to be able to read the attributes at runtime.

If it is available at compile time, it is implementable at runtime as a lib. So you pay for it only if you use it, and you don't add feature in the language just because it is convenient.
Apr 09 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-04-09 23:49, deadalnix wrote:

 If it is available at compile time, it is implementable at runtime as a
 lib. So you pay for it only if you use it, and you don't add feature in
 the language just because it is convenient.

I'm not saying how it should be implemented, just that it should be accessible at runtime. -- /Jacob Carlborg
Apr 09 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-04-10 13:41, Steven Schveighoffer wrote:
 On Tue, 10 Apr 2012 02:30:21 -0400, Jacob Carlborg <doob me.com> wrote:

 On 2012-04-09 23:49, deadalnix wrote:

 If it is available at compile time, it is implementable at runtime as a
 lib. So you pay for it only if you use it, and you don't add feature in
 the language just because it is convenient.

I'm not saying how it should be implemented, just that it should be accessible at runtime.

I think there was some confusion, read a quote of what you said: "I don't see why the attributes *should* be accessible at runtime" Emphasis added. I think you meant "shouldn't" -Steve

Yeah, I did, hehe :) This thread is getting too long now. -- /Jacob Carlborg
Apr 10 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-04-10 19:02, Marco Leise wrote:

 So in the end we more or less agree that Walter and others can implement
useful attributes for compile-time, whereas runtime support is nice-to-have (or
can be provided by a lib)? My intention is to make it easier for the one who
implements them if runtime support proves difficult.

Something like that. -- /Jacob Carlborg
Apr 10 2012
prev sibling parent Artur Skawina <art.08.09 gmail.com> writes:
On 04/10/12 12:32, Timon Gehr wrote:
 On 04/10/2012 12:18 AM, Walter Bright wrote:
 On 4/6/2012 3:49 AM, Timon Gehr wrote:
 On 04/06/2012 12:23 PM, Walter Bright wrote:
 On 4/6/2012 2:54 AM, Timon Gehr wrote:
 Should add additional information to the type Foo. I don't see any
 issues with
 it, and not supporting it would be very strange.

How would: attr(foo) int x; int y; work? Are x and y the same type or not?

Yes, they are. (But a future extension might leave this choice up to 'foo')
 Now, consider:

 auto c = b ? x : y;

 What type does c have? int or  attr(foo)int ? And that's really just the
 beginning. How about:

 struct S(T) {
 T t;
 }

 Instantiate it with S!int and S!( attr(foo)int). Are those the same
 instantiation, or different? If the same, does S.t have the attribute or
 not?

There is no such thing as an attr(foo) int, because attr is not a type constructor.

But you said it was added to the *type*.

What I said was that it is added to the declaration. If the declaration happens to declare a type, then that must affect the type: attr(foo) struct Foo{} // annotate 'foo' attr(bar) Foo x; __traits(getAttributes, typeof(x)); // this will find 'foo', but no 'bar' __traits(getAttributes, x); // this will find 'bar', but not 'foo'

The last one is the one i'm not sure about. What's the advantage of not reporting 'foo' for 'x'? "Inheriting" the attrs from the type seems attractive, what does separating the attributes achieve in practice? I'm assuming the type attributes do not influence the type in any way. While it would be great if one could also have type-changing attributes [1] in addition to the just annotating ones, i'm not going to propose that - there were too many too complicated proposals in these threads already... artur [1] think "shared" etc, or multiple string types.
Apr 10 2012
prev sibling next sibling parent "Kapps" <opantm2+spam gmail.com> writes:
On Friday, 6 April 2012 at 06:47:56 UTC, Walter Bright wrote:
 On 4/5/2012 5:00 AM, Manu wrote:
 C# and Java both have attributes, following these established

 don't think there should be any mystery over how they should

I was thinking of something along the lines of what has been proposed here earlier: attr(identifier = expression) as a storage class, like: attr(foo = bar + 1) int x; and then: __traits(hasAttribute, x, foo) would return true, and: __traits(getAttribute, x, foo) would return the expression (bar+1). The expression would be compile-time only, evaluated at the point of declaration. The implementation is simple enough, just attach to each symbol an array of (identifier,expression) pairs. You could also omit the expression, and just have: attr(bar) int y;

I like it for the most part. One thing I'd like to see is placing multiple attributes both by using multiple attr()'s, and by using comma separated identifier/expression pairs inside a single attr. In other words, the following two declarations would be identical. attr(Description = "Blah", ReadOnly) int ID; attr(Description = "Blah") attr(ReadOnly) int ID; My only concerns: First, attr() is a little verbose / not exactly pretty. This isn't really a big issue, since attributes aren't exactly piled on and it makes it easy to tell what's going on. It is a little uglier than in other languages however. Secondly, from what I can tell it's an arbitrary key value combo. What would happen if you're working on a larger project and two unrelated libraries try to use the same attribute name to mean different things? With the module system this issue doesn't exist since you have to import it and can selectively/privately do so, but from what I understand the method you're proposing doesn't declare the attribute itself at all. Am I just misunderstanding this part?
Apr 06 2012
prev sibling next sibling parent "Bernard Helyer" <b.helyer gmail.com> writes:
On Friday, 6 April 2012 at 06:47:56 UTC, Walter Bright wrote:
 On 4/5/2012 5:00 AM, Manu wrote:
 C# and Java both have attributes, following these established

 don't think there should be any mystery over how they should

I was thinking of something along the lines of what has been proposed here earlier: attr(identifier = expression) as a storage class, like: attr(foo = bar + 1) int x; and then: __traits(hasAttribute, x, foo) would return true, and: __traits(getAttribute, x, foo) would return the expression (bar+1). The expression would be compile-time only, evaluated at the point of declaration. The implementation is simple enough, just attach to each symbol an array of (identifier,expression) pairs. You could also omit the expression, and just have: attr(bar) int y;

I like it. Perhaps attr(bar) could be equivalent to attr(bar = true) so you don't get any weird failure state for __traits(getAttribute?
Apr 06 2012
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
Am Fri, 06 Apr 2012 00:48:34 -0700
schrieb Walter Bright <newshound2 digitalmars.com>:

 On 4/6/2012 12:35 AM, Alex R=C3=B8nne Petersen wrote:
 It actually can be a problem. In .NET land, there are many
 attributes across many projects (and even in the framework itself)
 with the same names. It turns out that regular namespace lookup
 rules alleviate this problem.

=20 Perhaps a better scheme is: =20 enum foo =3D 3; =20 ... =20 attr(foo) int x; =20 That way, foo will follow all the usual rules. =20

The last time custom attributes where discussed, a C# like model was proposed. Is there a good reason why we should deviate from the C# implementation? C#: http://msdn.microsoft.com/en-US/library/48zeb25s(v=3Dvs.80).aspx http://msdn.microsoft.com/en-US/library/sw480ze8(v=3Dvs.100).aspx http://msdn.microsoft.com/en-US/library/z919e8tw(v=3Dvs.80).aspx (C# attributes can be applied to almost everything, therefore sometimes "disambiguating targets" is necessary. Probably not needed in D): http://msdn.microsoft.com/en-US/library/b3787ac0(v=3Dvs.80).aspx Syntax in D would be different of course, but I see absolutely no need for the redundant (and ugly) attr. Declaring a custom attribute: --------- module std.something; struct Author { string name; public this(string name) { this.name =3D name; } } --------- Using it: --------- import std.something; //Usual namespace lookup rules apply to attributes /* * Author(param) calls the constructor of the Author struct and * attaches the struct instance to test. Probably Author (without * parenthesis) coud be made to mean std.something.Author.init=20 */ Author("Johannes Pfau") int test; --------- Attaching attributes multiple times as in C# should be possible. Using reflection to get that attribute: --------- if(__traits(hasAttribute, test, std.something.Author)) { Author[] authors =3D __traits(getAttribute, test, std.something.Author); } --------- An array is used here to support attaching the same attribute multiple times. Of course "auto authors =3D ..." should be usable here too.
Apr 06 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--20cf30050ec05ca37804bcffb03c
Content-Type: text/plain; charset=UTF-8

On 5 April 2012 20:35, Walter Bright <newshound2 digitalmars.com> wrote:

 On 4/5/2012 5:00 AM, Manu wrote:

 C# and Java both have attributes, following these established design
 patterns, I
 don't think there should be any mystery over how they should be
 implemented.

At the Lang.NEXT conference over the last 3 days, I was able to talk to many smart people about attributes. But I did find some confusion - are they best attached to the variable/function (i.e. "storage class"), or attached to the type ("type constructor")? I think the former. Attaching it to the type leads to all sorts of semantic issues. From your list of uses, it looks like attaching it to the variable or function is an apropos solution.

Yes, most certainly the former. The latter is already possible with tricks (a trivial template for instance). An attribute/annotation should associate with select instances/declarations of things. I don't think it should affect the type, although this shows a conceptual problem when referring to existing attributes via the same terminology. Obviously one might consider 'const', 'pure', etc attributes themselves, and they clearly do affect the type. Perhaps that's the key distinction between an ' ' attribute(/'annotation'?), and a no-' ' attribute? --20cf30050ec05ca37804bcffb03c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 5 April 2012 20:35, Walter Bright <span dir= =3D"ltr">&lt;<a href=3D"mailto:newshound2 digitalmars.com">newshound2 digit= almars.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style= =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On 4/5/2012 5:00 AM, Manu wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> C# and Java both have attributes, following these established design patter= ns, I<br> don&#39;t think there should be any mystery over how they should be impleme= nted.<br> </blockquote> <br></div> At the Lang.NEXT conference over the last 3 days, I was able to talk to man= y smart people about attributes. But I did find some confusion - are they b= est attached to the variable/function (i.e. &quot;storage class&quot;), or = attached to the type (&quot;type constructor&quot;)? I think the former. At= taching it to the type leads to all sorts of semantic issues.<br> <br>
From your list of uses, it looks like attaching it to the variable or funct=

</blockquote></div><br><div>Yes, most certainly the former. The latter is a= lready possible with tricks (a trivial template for instance).</div><div>An= attribute/annotation should associate with select instances/declarations o= f things.</div> <div>I don&#39;t think it should affect the type, although this shows a con= ceptual problem when referring to existing attributes via the same terminol= ogy. Obviously one might consider &#39;const&#39;, &#39;pure&#39;, etc attr= ibutes themselves, and they clearly do affect the type.</div> <div>Perhaps that&#39;s the key distinction between an &#39; &#39; attribut= e(/&#39;annotation&#39;?), and a no-&#39; &#39; attribute?</div> --20cf30050ec05ca37804bcffb03c--
Apr 06 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--20cf30050ec0eee58b04bcffb300
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 5 April 2012 21:32, Timon Gehr <timon.gehr gmx.ch> wrote:

 On 04/05/2012 08:05 PM, Andrei Alexandrescu wrote:

 On 4/5/12 12:44 PM, deadalnix wrote:

 Le 05/04/2012 19:35, Walter Bright a =C3=A9crit :

 On 4/5/2012 5:00 AM, Manu wrote:

 C# and Java both have attributes, following these established design
 patterns, I
 don't think there should be any mystery over how they should be
 implemented.

At the Lang.NEXT conference over the last 3 days, I was able to talk t=




 many smart people about attributes. But I did find some confusion - ar=




 they best attached to the variable/function (i.e. "storage class"), or
 attached to the type ("type constructor")? I think the former. Attachi=




 it to the type leads to all sorts of semantic issues.

 From your list of uses, it looks like attaching it to the variable or
 function is an apropos solution.

They should be attached to declarations.

The question was whether the declaration affects the type of the declared or not. Andrei

Ideally it would be powerful enough to allow changing the type, but most applications probably want the type to stay the same.

Didn't someone already say there were existing language defined attributes that could be neatly implemented via libs if the feature were available? Which ones were they? --20cf30050ec0eee58b04bcffb300 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 5 April 2012 21:32, Timon Gehr <span dir=3D"l= tr">&lt;<a href=3D"mailto:timon.gehr gmx.ch">timon.gehr gmx.ch</a>&gt;</spa= n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b= order-left:1px #ccc solid;padding-left:1ex"> <div class=3D"HOEnZb"><div class=3D"h5">On 04/05/2012 08:05 PM, Andrei Alex= andrescu wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On 4/5/12 12:44 PM, deadalnix wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Le 05/04/2012 19:35, Walter Bright a =C3=A9crit :<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On 4/5/2012 5:00 AM, Manu wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> C# and Java both have attributes, following these established design<br> patterns, I<br> don&#39;t think there should be any mystery over how they should be<br> implemented.<br> </blockquote> <br> At the Lang.NEXT conference over the last 3 days, I was able to talk to<br> many smart people about attributes. But I did find some confusion - are<br> they best attached to the variable/function (i.e. &quot;storage class&quot;= ), or<br> attached to the type (&quot;type constructor&quot;)? I think the former. At= taching<br> it to the type leads to all sorts of semantic issues.<br> <br>
From your list of uses, it looks like attaching it to the variable or<br>

</blockquote> <br> They should be attached to declarations.<br> </blockquote> <br> The question was whether the declaration affects the type of the<br> declared or not.<br> <br> Andrei<br> </blockquote> <br></div></div> Ideally it would be powerful enough to allow changing the type, but most ap= plications probably want the type to stay the same.<br> </blockquote></div><br><div>Didn&#39;t someone already say there were exist= ing language defined attributes that could be neatly implemented via libs i= f the feature were available? Which ones were they?</div> --20cf30050ec0eee58b04bcffb300--
Apr 06 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--20cf300fac5b827e3b04bcfffb9c
Content-Type: text/plain; charset=UTF-8

On 6 April 2012 09:47, Walter Bright <newshound2 digitalmars.com> wrote:

 On 4/5/2012 5:00 AM, Manu wrote:
 C# and Java both have attributes, following these established design

 don't think there should be any mystery over how they should be

I was thinking of something along the lines of what has been proposed here earlier: attr(identifier = expression) as a storage class, like: attr(foo = bar + 1) int x; and then: __traits(hasAttribute, x, foo) would return true, and: __traits(getAttribute, x, foo) would return the expression (bar+1). The expression would be compile-time only, evaluated at the point of declaration. The implementation is simple enough, just attach to each symbol an array of (identifier,expression) pairs. You could also omit the expression, and just have: attr(bar) int y;

I think this is unnecessarily verbose, although certainly workable as a minimum. Although there is one issue that 'foo' can't store compound data. I'd like to see attributes defined as a special sort of struct, and support constructors, this way you can associate rich data, and you can perform complex expressions (ctfe) within the constructor to set defaults, or calculate other details about the attribute if not specified. replay int x; // this is all that is needed if the attribute associates no variable information // or something associating consideraly more rich information editor("X coordinate", EditType.Slider, Colour.Red, "Verbose description about the thing") // this is still a lot easier to read to me... int x; --20cf300fac5b827e3b04bcfffb9c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 6 April 2012 09:47, Walter Bright <span dir= =3D"ltr">&lt;<a href=3D"mailto:newshound2 digitalmars.com">newshound2 digit= almars.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style= =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On 4/5/2012 5:00 AM, Manu wrote:<br> &gt; C# and Java both have attributes, following these established design p= atterns, I<br> &gt; don&#39;t think there should be any mystery over how they should be im= plemented.<br> <br></div> I was thinking of something along the lines of what has been proposed here = earlier:<br> <br> =C2=A0 attr(identifier =3D expression)<br> <br> as a storage class, like:<br> <br> =C2=A0 attr(foo =3D bar + 1) int x;<br> <br> and then:<br> <br> =C2=A0__traits(hasAttribute, x, foo)<br> <br> would return true, and:<br> <br> =C2=A0__traits(getAttribute, x, foo)<br> <br> would return the expression (bar+1). The expression would be compile-time o= nly, evaluated at the point of declaration.<br> <br> The implementation is simple enough, just attach to each symbol an array of= (identifier,expression) pairs.<br> <br> You could also omit the expression, and just have:<br> <br> =C2=A0 attr(bar) int y;<br> </blockquote></div><br><div>I think this is unnecessarily verbose, although= certainly workable as a minimum. Although there is one issue that &#39;foo= &#39; can&#39;t store compound data.</div><div>I&#39;d like to see attribut= es defined as a special sort of struct, and support constructors, this way = you can associate rich data, and you can perform complex expressions (ctfe)= within the constructor to set defaults, or calculate other details about t= he attribute if not specified.</div> <div><br></div><div> replay int x; // this is all that is needed if the att= ribute associates no variable information</div><div><br></div><div>// or so= mething associating consideraly more rich information</div><div> editor(&qu= ot;X coordinate&quot;, EditType.Slider, Colour.Red, &quot;Verbose descripti= on about the thing&quot;)=C2=A0// this is still a lot easier to read to me.= ..</div> <div>int x;</div> --20cf300fac5b827e3b04bcfffb9c--
Apr 06 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--20cf30050ec05326fc04bd000dc3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 6 April 2012 10:48, Walter Bright <newshound2 digitalmars.com> wrote:

 On 4/6/2012 12:35 AM, Alex R=C3=B8nne Petersen wrote:

 It actually can be a problem. In .NET land, there are many attributes
 across
 many projects (and even in the framework itself) with the same names. It
 turns
 out that regular namespace lookup rules alleviate this problem.

Perhaps a better scheme is: enum foo =3D 3; ... attr(foo) int x; That way, foo will follow all the usual rules.

What about: struct editor { this(string name, EditType, Colour =3D Colour.Default, string description= =3D null) { //... } blah blah blah } attr(editor("thing",...blah...)) I don't see the advantage over: editor(...) ? --20cf30050ec05326fc04bd000dc3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 6 April 2012 10:48, Walter Bright <span dir= =3D"ltr">&lt;<a href=3D"mailto:newshound2 digitalmars.com">newshound2 digit= almars.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style= =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On 4/6/2012 12:35 AM, Alex R=C3=B8nne Petersen wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> It actually can be a problem. In .NET land, there are many attributes acros= s<br> many projects (and even in the framework itself) with the same names. It tu= rns<br> out that regular namespace lookup rules alleviate this problem.<br> </blockquote> <br> <br></div> Perhaps a better scheme is:<br> <br> =C2=A0 enum foo =3D 3;<br> <br> =C2=A0 ...<br> <br> =C2=A0 attr(foo) int x;<br> <br> That way, foo will follow all the usual rules.<br> </blockquote></div><div><br></div>What about:<div><br></div><div>struct edi= tor</div><div>{</div><div>=C2=A0 this(string name, EditType, Colour =3D Col= our.Default, string description =3D null)</div><div>=C2=A0 {</div><div>=C2= =A0 =C2=A0 //...</div> <div>=C2=A0 }</div><div><br></div><div>=C2=A0 blah blah blah</div><div>}<br=
<div><div><br></div></div></div><div> attr(editor(&quot;thing&quot;,...bla=

iv> editor(...)</div> <div><br></div><div>?</div> --20cf30050ec05326fc04bd000dc3--
Apr 06 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--20cf30363eb72cb8b804bd00127f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 6 April 2012 12:41, Johannes Pfau <nospam example.com> wrote:

 Am Fri, 06 Apr 2012 00:48:34 -0700
 schrieb Walter Bright <newshound2 digitalmars.com>:

 On 4/6/2012 12:35 AM, Alex R=C3=B8nne Petersen wrote:
 It actually can be a problem. In .NET land, there are many
 attributes across many projects (and even in the framework itself)
 with the same names. It turns out that regular namespace lookup
 rules alleviate this problem.

Perhaps a better scheme is: enum foo =3D 3; ... attr(foo) int x; That way, foo will follow all the usual rules.

The last time custom attributes where discussed, a C# like model was proposed. Is there a good reason why we should deviate from the C# implementation? C#: http://msdn.microsoft.com/en-US/library/48zeb25s(v=3Dvs.80).aspx http://msdn.microsoft.com/en-US/library/sw480ze8(v=3Dvs.100).aspx http://msdn.microsoft.com/en-US/library/z919e8tw(v=3Dvs.80).aspx (C# attributes can be applied to almost everything, therefore sometimes "disambiguating targets" is necessary. Probably not needed in D): http://msdn.microsoft.com/en-US/library/b3787ac0(v=3Dvs.80).aspx Syntax in D would be different of course, but I see absolutely no need for the redundant (and ugly) attr. Declaring a custom attribute: --------- module std.something; struct Author { string name; public this(string name) { this.name =3D name; } } --------- Using it: --------- import std.something; //Usual namespace lookup rules apply to attributes /* * Author(param) calls the constructor of the Author struct and * attaches the struct instance to test. Probably Author (without * parenthesis) coud be made to mean std.something.Author.init */ Author("Johannes Pfau") int test; --------- Attaching attributes multiple times as in C# should be possible. Using reflection to get that attribute: --------- if(__traits(hasAttribute, test, std.something.Author)) { Author[] authors =3D __traits(getAttribute, test, std.something.Author); } --------- An array is used here to support attaching the same attribute multiple times. Of course "auto authors =3D ..." should be usable here too.

+1 --20cf30363eb72cb8b804bd00127f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 6 April 2012 12:41, Johannes Pfau <span dir= =3D"ltr">&lt;<a href=3D"mailto:nospam example.com">nospam example.com</a>&g= t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0= .8ex;border-left:1px #ccc solid;padding-left:1ex"> Am Fri, 06 Apr 2012 00:48:34 -0700<br> schrieb Walter Bright &lt;<a href=3D"mailto:newshound2 digitalmars.com">new= shound2 digitalmars.com</a>&gt;:<br> <div><div class=3D"h5"><br> &gt; On 4/6/2012 12:35 AM, Alex R=C3=B8nne Petersen wrote:<br> &gt; &gt; It actually can be a problem. In .NET land, there are many<br> &gt; &gt; attributes across many projects (and even in the framework itself= )<br> &gt; &gt; with the same names. It turns out that regular namespace lookup<b= r> &gt; &gt; rules alleviate this problem.<br> &gt;<br> &gt;<br> &gt; Perhaps a better scheme is:<br> &gt;<br> &gt; =C2=A0 =C2=A0 enum foo =3D 3;<br> &gt;<br> &gt; =C2=A0 =C2=A0 ...<br> &gt;<br> &gt; =C2=A0 =C2=A0 attr(foo) int x;<br> &gt;<br> &gt; That way, foo will follow all the usual rules.<br> &gt;<br> <br> </div></div>The last time custom attributes where discussed, a C# like mode= l was<br> proposed. Is there a good reason why we should deviate from the C#<br> implementation?<br> <br> C#:<br> <a href=3D"http://msdn.microsoft.com/en-US/library/48zeb25s(v=3Dvs.80).aspx= " target=3D"_blank">http://msdn.microsoft.com/en-US/library/48zeb25s(v=3Dvs= .80).aspx</a><br> <a href=3D"http://msdn.microsoft.com/en-US/library/sw480ze8(v=3Dvs.100).asp= x" target=3D"_blank">http://msdn.microsoft.com/en-US/library/sw480ze8(v=3Dv= s.100).aspx</a><br> <a href=3D"http://msdn.microsoft.com/en-US/library/z919e8tw(v=3Dvs.80).aspx= " target=3D"_blank">http://msdn.microsoft.com/en-US/library/z919e8tw(v=3Dvs= .80).aspx</a><br> <br> (C# attributes can be applied to almost everything, therefore sometimes<br> =C2=A0&quot;disambiguating targets&quot; is necessary. Probably not needed = in D):<br> <a href=3D"http://msdn.microsoft.com/en-US/library/b3787ac0(v=3Dvs.80).aspx= " target=3D"_blank">http://msdn.microsoft.com/en-US/library/b3787ac0(v=3Dvs= .80).aspx</a><br> <br> Syntax in D would be different of course, but I see absolutely no need<br> for the redundant (and ugly) attr.<br> <br> Declaring a custom attribute:<br> ---------<br> module std.something;<br> <br> struct Author<br> {<br> =C2=A0 =C2=A0string name;<br> =C2=A0 =C2=A0public this(string name)<br> =C2=A0 =C2=A0{<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"http://this.name" target=3D"_blank">= this.name</a> =3D name;<br> =C2=A0 =C2=A0}<br> }<br> ---------<br> <br> Using it:<br> ---------<br> import std.something; //Usual namespace lookup rules apply to attributes<br=

/*<br> =C2=A0* Author(param) calls the constructor of the Author struct and<br> =C2=A0* attaches the struct instance to test. Probably Author (without<br> =C2=A0* parenthesis) coud be made to mean std.something.Author.init<br> =C2=A0*/<br> Author(&quot;Johannes Pfau&quot;) int test;<br> ---------<br> <br> Attaching attributes multiple times as in C# should be possible.<br> <br> Using reflection to get that attribute:<br> ---------<br> if(__traits(hasAttribute, test, std.something.Author))<br> {<br> =C2=A0 =C2=A0Author[] authors =3D __traits(getAttribute, test,<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0std.something.Author);<br> }<br> ---------<br> <br> An array is used here to support attaching the same attribute multiple<br> times. Of course &quot;auto authors =3D ...&quot; should be usable here too= .<br> </blockquote></div><br><div>+1</div> --20cf30363eb72cb8b804bd00127f--
Apr 06 2012
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
Am Fri, 06 Apr 2012 03:06:51 -0700
schrieb Walter Bright <newshound2 digitalmars.com>:

 On 4/6/2012 2:41 AM, Johannes Pfau wrote:
 The last time custom attributes where discussed, a C# like model was
 proposed. Is there a good reason why we should deviate from the C#
 implementation?

C# uses a runtime implementation, not a compile time one.

OK, but my post was only about the syntax, there's no runtime/compile time specific part in it (the struct's constructor has to be called using CTFE instead of at runtime, but that's the only difference I see)
Apr 06 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--20cf302ef74cc2078c04bd00319d
Content-Type: text/plain; charset=UTF-8

On 6 April 2012 13:06, Timon Gehr <timon.gehr gmx.ch> wrote:

 On 04/06/2012 11:57 AM, Manu wrote:

 I don't think it should affect the type, although this shows a
 conceptual problem when referring to existing attributes via the same
 terminology. Obviously one might consider 'const', 'pure', etc
 attributes themselves, and they clearly do affect the type.
 Perhaps that's the key distinction between an ' '
 attribute(/'annotation'?), and a no-' ' attribute?

safe affects the type.

I realise that, I'm just suggesting this is a possible solution to the confusion... if the distinction were to be made clearly. I guess it's impossible though, can't go claiming 'safe' from the global namespace :) --20cf302ef74cc2078c04bd00319d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 6 April 2012 13:06, Timon Gehr <span dir=3D"l= tr">&lt;<a href=3D"mailto:timon.gehr gmx.ch">timon.gehr gmx.ch</a>&gt;</spa= n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b= order-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On 04/06/2012 11:57 AM, Manu wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> I don&#39;t think it should affect the type, although this shows a<br> conceptual problem when referring to existing attributes via the same<br> terminology. Obviously one might consider &#39;const&#39;, &#39;pure&#39;, = etc<br> attributes themselves, and they clearly do affect the type.<br> Perhaps that&#39;s the key distinction between an &#39; &#39;<br> attribute(/&#39;annotation&#39;?), and a no-&#39; &#39; attribute?<br> </blockquote> <br></div> safe affects the type.<br> </blockquote></div><br><div>I realise that, I&#39;m just suggesting this is= a possible solution to the confusion... if the distinction were to be made= clearly.</div><div>I guess it&#39;s impossible though, can&#39;t go claimi= ng &#39;safe&#39; from the global namespace :)</div> --20cf302ef74cc2078c04bd00319d--
Apr 06 2012
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
Am Fri, 06 Apr 2012 12:43:27 +0200
schrieb Timon Gehr <timon.gehr gmx.ch>:

 On 04/06/2012 12:28 PM, Walter Bright wrote:
 On 4/6/2012 3:23 AM, Manu wrote:
 I don't see the advantage over:
  editor(...)

 ?

Name collisions with other attributes.

Which other attributes? Built-in ones? Otherwise, the D module system will be great at disambiguating the collisions as soon as inaccessible private symbols do not participate in symbol name collisions any more. Maybe we could just keep all the lower case attributes reserved in order to be future proof.

Or add a reserved pseudo-namespace (like e.g 'builtin') for compiler defined attributes and use normal namespace resolution for those: safe <=> builtin.safe
Apr 06 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--00235452f834fa403e04bd006e59
Content-Type: text/plain; charset=UTF-8

On 6 April 2012 13:12, Walter Bright <newshound2 digitalmars.com> wrote:

 On 4/6/2012 2:50 AM, Ary Manzana wrote:

 The syntax in Java for declaring an attribute:

 public  interface Foo {
 String xxx;
 int yyy;
 }

 In D maybe  interface could be used to (in order to avoid introducing
 another
 keyword... or maybe use  attribute instead):

  attribute Foo {
 string xxx;
 int yyy;
 }

I don't see the need for creating a new kind of symbol.

I don't think it's necessary to declare the struct as attribute explicitly, the ' ' can easily imply the usage all on its own in the declaration. The struct would remain a perfectly normal struct, and will be useful if you want to get a struct somewhere in the code to inspect details about the attribute. SomeStruct(blah) int x; .. SomeStruct s = __traits(getAttribute, SomeStruct, x); ... do some stuff with the information that x was attributed static if(s.thing == ??)
 2. You use them by using their names. What you are proposing if for
 attribute
 foo to be  attr(foo). But in Java it's  foo.

 So in Java you would use that attribute like this:

  Foo(xxx = "hello", yyy = 1);
 void func() {}

 Then you can get the "Foo" attribute in func, and ask for it's xxx and
 yyy.

This is a runtime system.

It doesn't need to be runtime. The syntax works perfectly at compile time? Now, your proposal is much simpler and it will become inconvenient in some
 cases. For example suppose you want to provide attributes for
 serialization (I
 guess the classic example). With your proposal it would be:

 /// This is actually an attribute. Use this together with serialized_name.
 enum serialize = 1;
 enum serialized_name = 2;

  attr(serialize = true, serialized_name = "Foo")
 int x;

No, it would be: enum serialize = true; enum serialize_name = "Foo"; attr(serialize, serialized_name) int x; There would be no initialization in the attr syntax.

Please don't. We've gone from a minor case of bracket spam now to a whole bunch of extra lines for every single member, and you've also removed the tight syntactical connection of the values from their attribute declaration (one of the most important details, its safety, when people update/edit classes). This is fast approaching the disconnected enum table which is the whole thing we're trying to avoid. There's also a namespace/scope problem here. 2 different systems from 2 different libraries will almost certainly use the 'serialise' attribute. Now, with the way things are done in Java and C#:
 /// Marks a field to be serialized.
  attribute serialize {
 /// The name to be used.
 /// If not specified, the name of the member will be used instead.
 string name;
 }

  serialize(name = "Foo")
 int x;

 You can see the syntax is much cleaner. The attribute declaration also
 serves as
 documentation and to group attributes related to the serialization
 process.

I don't see that it is cleaner - there's no particular reason why a new symbol type needs to be introduced.

See my point above, I don't think there's any need for a new symbol type... The compiler would just keep a little table of attributes alongside declarations, which you can query if you want to. --00235452f834fa403e04bd006e59 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 6 April 2012 13:12, Walter Bright <span dir= =3D"ltr">&lt;<a href=3D"mailto:newshound2 digitalmars.com">newshound2 digit= almars.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style= =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On 4/6/2012 2:50 AM, Ary Manzana wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> The syntax in Java for declaring an attribute:<br> <br> public interface Foo {<br> String xxx;<br> int yyy;<br> }<br> <br> In D maybe interface could be used to (in order to avoid introducing anoth= er<br> keyword... or maybe use attribute instead):<br> <br> attribute Foo {<br> string xxx;<br> int yyy;<br> }<br> </blockquote> <br></div> I don&#39;t see the need for creating a new kind of symbol.</blockquote><di= v><br></div><div>I don&#39;t think it&#39;s necessary to declare the struct= as attribute explicitly, the &#39; &#39; can easily imply the usage all o= n its own in the declaration. The struct would remain a perfectly normal st= ruct, and will be useful if you want to get a struct somewhere in the code = to inspect details about the attribute.</div> <div><br></div><div> SomeStruct(blah) int x;</div><div><br></div><div>..</d= iv><div><br></div><div><br></div><div>SomeStruct s =3D __traits(getAttribut= e,=C2=A0 SomeStruct, x);</div><div>... do some stuff with the information that x was= attributed</div><div>static if(s.thing =3D=3D ??)</div><div><br></div><div=
<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"marg=

<div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .= 8ex;border-left:1px #ccc solid;padding-left:1ex">2. You use them by using t= heir names. What you are proposing if for attribute<br> foo to be attr(foo). But in Java it&#39;s foo.<br> <br> So in Java you would use that attribute like this:<br> <br> Foo(xxx =3D &quot;hello&quot;, yyy =3D 1);<br> void func() {}<br> <br> Then you can get the &quot;Foo&quot; attribute in func, and ask for it&#39;= s xxx and yyy.<br> </blockquote> <br></div> This is a runtime system.</blockquote><div><br></div><div>It doesn&#39;t ne= ed to be runtime. The syntax works perfectly at compile time?</div><div>=C2= =A0</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0= 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .= 8ex;border-left:1px #ccc solid;padding-left:1ex">Now, your proposal is much= simpler and it will become inconvenient in some<br> cases. For example suppose you want to provide attributes for serialization= (I<br> guess the classic example). With your proposal it would be:<br> <br> /// This is actually an attribute. Use this together with serialized_name.<= br> enum serialize =3D 1;<br> enum serialized_name =3D 2;<br> <br> attr(serialize =3D true, serialized_name =3D &quot;Foo&quot;)<br> int x;<br> </blockquote> <br></div> No, it would be:<br> <br> =C2=A0 enum serialize =3D true;<br> =C2=A0 enum serialize_name =3D &quot;Foo&quot;;<br> =C2=A0 attr(serialize, serialized_name) int x;<br> <br> There would be no initialization in the attr syntax.</blockquote><div><br>= </div><div>Please don&#39;t. We&#39;ve gone from a minor case of bracket sp= am now to a whole bunch of extra lines for every single member, and you&#39= ;ve also removed the tight syntactical connection of the values from their = attribute declaration (one of the most important details, its safety, when = people update/edit classes). This is fast approaching the disconnected enum= table which is the whole thing we&#39;re trying to avoid.</div> <div>There&#39;s also a namespace/scope problem here. 2 different systems f= rom 2 different libraries will almost certainly use the &#39;serialise&#39;= attribute.</div><div><br></div><div><br></div><blockquote class=3D"gmail_q= uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e= x"> <div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .= 8ex;border-left:1px #ccc solid;padding-left:1ex">Now, with the way things a= re done in Java and C#:<br> <br> /// Marks a field to be serialized.<br> attribute serialize {<br> /// The name to be used.<br> /// If not specified, the name of the member will be used instead.<br> string name;<br> }<br> <br> serialize(name =3D &quot;Foo&quot;)<br> int x;<br> <br> You can see the syntax is much cleaner. The attribute declaration also serv= es as<br> documentation and to group attributes related to the serialization process.= <br> </blockquote> <br></div> I don&#39;t see that it is cleaner - there&#39;s no particular reason why a= new symbol type needs to be introduced.</blockquote><div><br></div><div>Se= e my point above, I don&#39;t think there&#39;s any need for a new symbol t= ype... The compiler would just keep a little table of attributes alongside = declarations, which you can query if you want to.</div> </div> --00235452f834fa403e04bd006e59--
Apr 06 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--20cf30363eb7adfcce04bd00a9d3
Content-Type: text/plain; charset=UTF-8

On 6 April 2012 13:28, Walter Bright <newshound2 digitalmars.com> wrote:

 On 4/6/2012 3:23 AM, Manu wrote:

 What about:

 struct editor
 {
   this(string name, EditType, Colour = Colour.Default, string description
 = null)
   {
     //...
   }

   blah blah blah
 }

  attr(editor("thing",...blah..**.))

Are you really changing the arguments for every declaration? Or is it one set that is repeated everywhere?

Of course, what's the point otherwise? This is the very definition of annotation. Everything needs to be exposed in the editor differently. The power of attributes are that they are tightly syntactically bound to the items they attribute. Nobody can change any class/struct without having the syntax force them to make any necessary corrections to their attributes too. I don't see the advantage over:
  editor(...)

 ?

Name collisions with other attributes.

If they were declared as normal structs, they would follow normal namespace rules. company.lib.MyAttribute(...) should also be a valid expression. The only collisions are trusted, safe... I think programmers can handle a few reserved keywords. I already can't go and name a variable whatever I want for the same reason: int private = 10; --20cf30363eb7adfcce04bd00a9d3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 6 April 2012 13:28, Walter Bright <span dir= =3D"ltr">&lt;<a href=3D"mailto:newshound2 digitalmars.com">newshound2 digit= almars.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style= =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On 4/6/2012 3:23 AM, Manu wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> What about:<br> <br> struct editor<br> {<br> =C2=A0 this(string name, EditType, Colour =3D Colour.Default, string descr= iption =3D null)<br> =C2=A0 {<br> =C2=A0 =C2=A0 //...<br> =C2=A0 }<br> <br> =C2=A0 blah blah blah<br> }<br> <br> attr(editor(&quot;thing&quot;,...blah..<u></u>.))<br> </blockquote> <br></div> Are you really changing the arguments for every declaration? Or is it one s= et that is repeated everywhere?<br></blockquote><div><br></div><div>Of cour= se, what&#39;s the point otherwise? This is the very definition of annotati= on.</div> <div>Everything needs to be exposed in the editor differently.</div><div><b= r></div><div>The power of attributes are that they are tightly syntacticall= y bound to the items they attribute. Nobody can change any class/struct wit= hout having the syntax force them to make any necessary corrections to thei= r attributes too.</div> <div><br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"ma= rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote cl= ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p= adding-left:1ex"> I don&#39;t see the advantage over:<br> editor(...)<br> <br> ?<br> </blockquote> <br> Name collisions with other attributes.<br></blockquote><div><br></div><di= v>If they were declared as normal structs, they would follow normal namespa= ce rules.</div><div><br></div><div> company.lib.MyAttribute(...) should als= o be a valid expression.</div> <div><br></div><div>The only collisions are trusted, safe... I think prog= rammers can handle a few reserved keywords.</div><div>I already can&#39;t g= o and name a variable whatever I want for the same reason:=C2=A0int private= =3D 10;</div> </div> --20cf30363eb7adfcce04bd00a9d3--
Apr 06 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--00235452f834de998104bd00d8a6
Content-Type: text/plain; charset=UTF-8

On 6 April 2012 13:23, Walter Bright <newshound2 digitalmars.com> wrote:

 On 4/6/2012 2:54 AM, Timon Gehr wrote:

 Should add additional information to the type Foo. I don't see any issues
 with
 it, and not supporting it would be very strange.

How would: attr(foo) int x; int y; work? Are x and y the same type or not?

Yes they are the same type.
 Now, consider:

   auto c = b ? x : y;

c was not attributed, and has no attributes. blah auto c = b ? x : y; // NOW 'c' is attributed with 'blah', as useless as that is :) Attributes are on the declaration, and not passed around. --00235452f834de998104bd00d8a6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 6 April 2012 13:23, Walter Bright <span dir= =3D"ltr">&lt;<a href=3D"mailto:newshound2 digitalmars.com" target=3D"_blank= ">newshound2 digitalmars.com</a>&gt;</span> wrote:<br><blockquote class=3D"= gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-= left:1ex"> <div>On 4/6/2012 2:54 AM, Timon Gehr wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Should add additional information to the type Foo. I don&#39;t see any issu= es with<br> it, and not supporting it would be very strange.<br> </blockquote> <br></div> How would:<br> <br> =C2=A0 attr(foo) int x;<br> =C2=A0 int y;<br> <br> work? Are x and y the same type or not?</blockquote><div><br></div><div>Yes= they are the same type.</div><div><br></div><div>=C2=A0</div><blockquote c= lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;= padding-left:1ex"> Now, consider:<br> <br> =C2=A0 auto c =3D b ? x : y;<br></blockquote><div><br></div><div>c was not= attributed, and has no attributes.</div><div> blah auto c =3D=C2=A0b ? x := y; // NOW &#39;c&#39; is attributed with &#39;blah&#39;, as useless as tha= t is :)</div> <div><br></div><div>Attributes are on the declaration, and not passed aroun= d.</div></div> --00235452f834de998104bd00d8a6--
Apr 06 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--00248c711a112c00be04bd01548a
Content-Type: text/plain; charset=UTF-8

On 6 April 2012 14:03, Timon Gehr <timon.gehr gmx.ch> wrote:
 It's a maze of complex decisions.

I think you can add a list of annotations to the class in the AST that represents a declaration (the common superclass of all declarations) and everything will just work.

Yeah, I always imagined it being about that simple too... are you able to proof the concept? (I know Java does this. But Java has a trivial type system compared with
 D. It doesn't even have type aliases. It doesn't have type constructors.
 Etc.)

I think there is some sort of communication problem, because the feature that is being requested is quite simple. It would probably be valuable if you could point out the issues you see in detail (using example code.)

Indeed. --00248c711a112c00be04bd01548a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 6 April 2012 14:03, Timon Gehr <span dir=3D"l= tr">&lt;<a href=3D"mailto:timon.gehr gmx.ch">timon.gehr gmx.ch</a>&gt;</spa= n> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde= r-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .= 8ex;border-left:1px #ccc solid;padding-left:1ex">It&#39;s a maze of complex= decisions.<br> </blockquote> <br></div> I think you can add a list of annotations to the class in the AST that repr= esents a declaration (the common superclass of all declarations) and everyt= hing will just work.</blockquote><div><br></div><div>Yeah, I always imagine= d it being about that simple too... are you able to proof the concept?</div=

rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"= im"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef= t:1px #ccc solid;padding-left:1ex"> (I know Java does this. But Java has a trivial type system compared with<br=

tors.<br> Etc.)<br> </blockquote> <br></div> I think there is some sort of communication problem, because the feature th= at is being requested is quite simple. It would probably be valuable if you= could point out the issues you see in detail (using example code.)</blockq= uote> <div><br></div><div>Indeed.</div></div> --00248c711a112c00be04bd01548a--
Apr 06 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--20cf30363eb77aa25304bd022bce
Content-Type: text/plain; charset=UTF-8

On 6 April 2012 15:38, Piotr Szturmaj <bncrbme jadamspam.pl> wrote:

 Jacob Carlborg wrote:

 I would like to have the possibility to attach attributes to types and
 parameters as well. Some think like this:

 class Bar
 {
  not_null(Foo) bar ( custom int a) {}
 }

 Where  not_null is attached to "Foo" and  custom is attached to "a".

Do you mean return type? I think your syntax has some serious disadvantages. Consider parameters and multiple attributes. For return types I'd like to see something like this: return: not_null return: MyAttr("foo") Foo bar( custom int a) {} This is similar to C#'s [return: MyAttr]. Alternatively it might be: return(not_null) return(MyAttr("foo"))

There's no need to attribute a return value. A) I think you're confusing it with attributing *types* again, and B) you can just attribute the function its self, and have access to precisely the same information. You can't attribute a return value, since attributes aren't transferred along with assignments, they are bound to their respective declaration. --20cf30363eb77aa25304bd022bce Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 6 April 2012 15:38, Piotr Szturmaj <span dir= =3D"ltr">&lt;<a href=3D"mailto:bncrbme jadamspam.pl">bncrbme jadamspam.pl</= a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0= 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">Jacob Carlborg wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> I would like to have the possibility to attach attributes to types and<br> parameters as well. Some think like this:<br> <br> class Bar<br> {<br> not_null(Foo) bar ( custom int a) {}<br> }<br> <br> Where not_null is attached to &quot;Foo&quot; and custom is attached to &= quot;a&quot;.<br> </blockquote> <br></div> Do you mean return type? I think your syntax has some serious disadvantages= . Consider parameters and multiple attributes.<br> <br> For return types I&#39;d like to see something like this:<br> <br> return: not_null<br> return: MyAttr(&quot;foo&quot;)<br> Foo bar( custom int a) {}<br> <br> This is similar to C#&#39;s [return: MyAttr]. Alternatively it might be:<br=

return(not_null)<br> return(MyAttr(&quot;foo&quot;))<br> </blockquote></div><br><div>There&#39;s no need to attribute a return value= . A) I think you&#39;re confusing it with attributing *types* again, and B)= you can just attribute the function its self, and have access to precisely= the same information.</div> <div>You can&#39;t attribute a return value, since attributes aren&#39;t tr= ansferred along with assignments, they are bound to their respective declar= ation.</div> --20cf30363eb77aa25304bd022bce--
Apr 06 2012
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 06 Apr 2012 03:54:15 -0400, Walter Bright  =

<newshound2 digitalmars.com> wrote:

 On 4/6/2012 12:49 AM, Alex R=C3=B8nne Petersen wrote:
 What about type declarations? I think those ought to be supported too=


 E.g. it
 makes sense to mark an entire type as  attr(serializable) (or the  =


 inverse).

That would make it a "type constructor", not a storage class, which we=

 talked about earlier in the thread. I refer you to that discussion.

I think there is a huge misunderstanding here. A type constructor alters a type. Annotations are not type constructors= . for example: class C {} foo class D {} foo C c; foo2 D d; D d2 =3D d; In all these cases, the foo or foo2 affects the *declaration*, not the= = *type*. So: 1. D's type is not affected, it's still class D. But an annotation has = = been stored on the *symbol* D, such that it can be looked up later. 2. annotations on variables do *not* affect the type of the variable. T= he = assignment to d2 works fine. 3. The following symbols have annotations attached to them: C: none D: foo c: foo d: foo2 d2: none Note that d and d2 have no annotations attached even though they are of = = type D. Because the type isn't affected by annotations. An annotation is simply metadata, stored in the compiler, and looked up = = via compiler directives. Optionally (and I would encourage this), = TypeInfo would store annotations on type declarations for retrieval at = runtime. -Steve
Apr 06 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--0023544718dcc4bade04bd024dc6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 6 April 2012 15:58, Steven Schveighoffer <schveiguy yahoo.com> wrote:

 On Fri, 06 Apr 2012 03:54:15 -0400, Walter Bright <
 newshound2 digitalmars.com> wrote:

  On 4/6/2012 12:49 AM, Alex R=C3=B8nne Petersen wrote:
 What about type declarations? I think those ought to be supported too.
 E.g. it
 makes sense to mark an entire type as  attr(serializable) (or the
 inverse).

That would make it a "type constructor", not a storage class, which we talked about earlier in the thread. I refer you to that discussion.

I think there is a huge misunderstanding here. A type constructor alters a type. Annotations are not type constructors. for example: class C {} foo class D {} foo C c; foo2 D d; D d2 =3D d; In all these cases, the foo or foo2 affects the *declaration*, not the *type*. So: 1. D's type is not affected, it's still class D. But an annotation has been stored on the *symbol* D, such that it can be looked up later. 2. annotations on variables do *not* affect the type of the variable. Th=

 assignment to d2 works fine.
 3. The following symbols have annotations attached to them:
  C: none
  D:  foo
  c:  foo
  d:  foo2
  d2: none

 Note that d and d2 have no annotations attached even though they are of
 type D.  Because the type isn't affected by annotations.

Just to clarify, typeof(d) and typeof(d2) (ie, both D's) are still annotated with foo, right? This is precisely how I imagine it to be. An annotation is simply metadata, stored in the compiler, and looked up via
 compiler directives.  Optionally (and I would encourage this), TypeInfo
 would store annotations on type declarations for retrieval at runtime.

I agree, and I would also encourage this. --0023544718dcc4bade04bd024dc6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 6 April 2012 15:58, Steven Schveighoffer <spa= n dir=3D"ltr">&lt;<a href=3D"mailto:schveiguy yahoo.com">schveiguy yahoo.co= m</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi= n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"HOEnZb"><div class=3D"h5">On Fri, 06 Apr 2012 03:54:15 -0400,= Walter Bright &lt;<a href=3D"mailto:newshound2 digitalmars.com" target=3D"= _blank">newshound2 digitalmars.com</a>&gt; wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On 4/6/2012 12:49 AM, Alex R=C3=B8nne Petersen wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> What about type declarations? I think those ought to be supported too. E.g.= it<br> makes sense to mark an entire type as attr(serializable) (or the inverse).= <br> </blockquote> <br> <br> That would make it a &quot;type constructor&quot;, not a storage class, whi= ch we talked about earlier in the thread. I refer you to that discussion.<b= r> </blockquote> <br></div></div> I think there is a huge misunderstanding here.<br> <br> A type constructor alters a type. =C2=A0Annotations are not type constructo= rs.<br> <br> for example:<br> <br> class C {}<br> <br> foo class D {}<br> <br> foo C c;<br> foo2 D d;<br> D d2 =3D d;<br> <br> In all these cases, the foo or foo2 affects the *declaration*, not the *t= ype*. =C2=A0So:<br> <br> 1. D&#39;s type is not affected, it&#39;s still class D. =C2=A0But an annot= ation has been stored on the *symbol* D, such that it can be looked up late= r.<br> 2. annotations on variables do *not* affect the type of the variable. =C2= =A0The assignment to d2 works fine.<br> 3. The following symbols have annotations attached to them:<br> =C2=A0C: none<br> =C2=A0D: foo<br> =C2=A0c: foo<br> =C2=A0d: foo2<br> =C2=A0d2: none<br> <br> Note that d and d2 have no annotations attached even though they are of typ= e D. =C2=A0Because the type isn&#39;t affected by annotations.<br></blockqu= ote><div><br></div><div>Just to clarify, typeof(d) and typeof(d2) (ie, both= D&#39;s) are still annotated with foo, right? This is precisely how I imag= ine it to be.</div> <div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex= ;border-left:1px #ccc solid;padding-left:1ex">An annotation is simply metad= ata, stored in the compiler, and looked up via compiler directives. =C2=A0O= ptionally (and I would encourage this), TypeInfo would store annotations on= type declarations for retrieval at runtime.<br> </blockquote><div><br></div><div>I agree, and I would also encourage this.<= /div></div> --0023544718dcc4bade04bd024dc6--
Apr 06 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--00248c711a119170af04bd025854
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 6 April 2012 15:13, deadalnix <deadalnix gmail.com> wrote:

 Le 06/04/2012 11:41, Johannes Pfau a =C3=A9crit :

  Am Fri, 06 Apr 2012 00:48:34 -0700
 schrieb Walter Bright<newshound2 digitalmars.**com<newshound2 digitalmar=


:

On 4/6/2012 12:35 AM, Alex R=C3=B8nne Petersen wrote:
 It actually can be a problem. In .NET land, there are many
 attributes across many projects (and even in the framework itself)
 with the same names. It turns out that regular namespace lookup
 rules alleviate this problem.

Perhaps a better scheme is: enum foo =3D 3; ... attr(foo) int x; That way, foo will follow all the usual rules.

proposed. Is there a good reason why we should deviate from the C# implementation? C#: http://msdn.microsoft.com/en-**US/library/48zeb25s(v=3Dvs.80).**aspx<htt=


 http://msdn.microsoft.com/en-**US/library/sw480ze8(v=3Dvs.100).**aspx<ht=


 http://msdn.microsoft.com/en-**US/library/z919e8tw(v=3Dvs.80).**aspx<htt=


 (C# attributes can be applied to almost everything, therefore sometimes
  "disambiguating targets" is necessary. Probably not needed in D):
 http://msdn.microsoft.com/en-**US/library/b3787ac0(v=3Dvs.80).**aspx<htt=


 Syntax in D would be different of course, but I see absolutely no need
 for the redundant (and ugly)  attr.

 Declaring a custom attribute:
 ---------
 module std.something;

 struct Author
 {
     string name;
     public this(string name)
     {
         this.name =3D name;
     }
 }
 ---------

 Using it:
 ---------
 import std.something; //Usual namespace lookup rules apply to attributes

 /*
  *  Author(param) calls the constructor of the Author struct and
  * attaches the struct instance to test. Probably  Author (without
  * parenthesis) coud be made to mean std.something.Author.init
  */
  Author("Johannes Pfau") int test;
 ---------

 Attaching attributes multiple times as in C# should be possible.

 Using reflection to get that attribute:
 ---------
 if(__traits(hasAttribute, test, std.something.Author))
 {
     Author[] authors =3D __traits(getAttribute, test,
         std.something.Author);
 }
 ---------

 An array is used here to support attaching the same attribute multiple
 times. Of course "auto authors =3D ..." should be usable here too.


This is precisely how I have always imagined the system working. Walter: can you comment why you think this is not do-able, or not a good way to go about it? --00248c711a119170af04bd025854 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 6 April 2012 15:13, deadalnix <span dir=3D"lt= r">&lt;<a href=3D"mailto:deadalnix gmail.com" target=3D"_blank">deadalnix g= mail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style= =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Le 06/04/2012 11:41, Johannes Pfau a =C3=A9crit :<div><div><br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Am Fri, 06 Apr 2012 00:48:34 -0700<br> schrieb Walter Bright&lt;<a href=3D"mailto:newshound2 digitalmars.com" targ= et=3D"_blank">newshound2 digitalmars.<u></u>com</a>&gt;:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On 4/6/2012 12:35 AM, Alex R=C3=B8nne Petersen wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> It actually can be a problem. In .NET land, there are many<br> attributes across many projects (and even in the framework itself)<br> with the same names. It turns out that regular namespace lookup<br> rules alleviate this problem.<br> </blockquote> <br> <br> Perhaps a better scheme is:<br> <br> =C2=A0 =C2=A0 enum foo =3D 3;<br> <br> =C2=A0 =C2=A0 ...<br> <br> =C2=A0 =C2=A0 attr(foo) int x;<br> <br> That way, foo will follow all the usual rules.<br> <br> </blockquote> <br> The last time custom attributes where discussed, a C# like model was<br> proposed. Is there a good reason why we should deviate from the C#<br> implementation?<br> <br> C#:<br> <a href=3D"http://msdn.microsoft.com/en-US/library/48zeb25s(v=3Dvs.80).aspx= " target=3D"_blank">http://msdn.microsoft.com/en-<u></u>US/library/48zeb25s= (v=3Dvs.80).<u></u>aspx</a><br> <a href=3D"http://msdn.microsoft.com/en-US/library/sw480ze8(v=3Dvs.100).asp= x" target=3D"_blank">http://msdn.microsoft.com/en-<u></u>US/library/sw480ze= 8(v=3Dvs.100).<u></u>aspx</a><br> <a href=3D"http://msdn.microsoft.com/en-US/library/z919e8tw(v=3Dvs.80).aspx= " target=3D"_blank">http://msdn.microsoft.com/en-<u></u>US/library/z919e8tw= (v=3Dvs.80).<u></u>aspx</a><br> <br> (C# attributes can be applied to almost everything, therefore sometimes<br> =C2=A0&quot;disambiguating targets&quot; is necessary. Probably not needed= in D):<br> <a href=3D"http://msdn.microsoft.com/en-US/library/b3787ac0(v=3Dvs.80).aspx= " target=3D"_blank">http://msdn.microsoft.com/en-<u></u>US/library/b3787ac0= (v=3Dvs.80).<u></u>aspx</a><br> <br> Syntax in D would be different of course, but I see absolutely no need<br> for the redundant (and ugly) attr.<br> <br> Declaring a custom attribute:<br> ---------<br> module std.something;<br> <br> struct Author<br> {<br> =C2=A0 =C2=A0 string name;<br> =C2=A0 =C2=A0 public this(string name)<br> =C2=A0 =C2=A0 {<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"http://this.name" target=3D"_blank"=
this.name</a> =3D name;<br>

}<br> ---------<br> <br> Using it:<br> ---------<br> import std.something; //Usual namespace lookup rules apply to attributes<br=

/*<br> =C2=A0* Author(param) calls the constructor of the Author struct and<br> =C2=A0* attaches the struct instance to test. Probably Author (without<br=

=C2=A0*/<br> Author(&quot;Johannes Pfau&quot;) int test;<br> ---------<br> <br> Attaching attributes multiple times as in C# should be possible.<br> <br> Using reflection to get that attribute:<br> ---------<br> if(__traits(hasAttribute, test, std.something.Author))<br> {<br> =C2=A0 =C2=A0 Author[] authors =3D __traits(getAttribute, test,<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 std.something.Author);<br> }<br> ---------<br> <br> An array is used here to support attaching the same attribute multiple<br> times. Of course &quot;auto authors =3D ...&quot; should be usable here too= .<br> <br> </blockquote> <br></div></div> That is a really nice proposal !<br> </blockquote></div><br><div>This is precisely how I have always imagined th= e system working. Walter: can you comment why you think this is not do-able= , or not a good way to go about it?</div> --00248c711a119170af04bd025854--
Apr 06 2012
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 06 Apr 2012 09:04:58 -0400, Manu <turkeyman gmail.com> wrote:

 On 6 April 2012 15:58, Steven Schveighoffer <schveiguy yahoo.com> wrote:

 Note that d and d2 have no annotations attached even though they are of
 type D.  Because the type isn't affected by annotations.

Just to clarify, typeof(d) and typeof(d2) (ie, both D's) are still annotated with foo, right? This is precisely how I imagine it to be.

Correct. -Steve
Apr 06 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Friday, 6 April 2012 at 06:47:56 UTC, Walter Bright wrote:
 I was thinking of something along the lines of what has been 
 proposed here earlier:

    attr(identifier = expression)

The identifier in there is a liability because of name conflicts. Instead, use typeof(expression) to identify it. Since two types can't have the same fully qualified name, it will never conflict. Jacob and I disagreed on some details, but both our proposals in the last thread had this in common. Java does it this way, too. Here's the other thread: http://forum.dlang.org/thread/bccwycoexxykfgxvedix forum.dlang.org
Apr 06 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Friday, 6 April 2012 at 12:52:27 UTC, Jacob Carlborg wrote:
 Just as we have today with keywords and symbols, I don't see 
 the problem.

Things like safe aren't keywords though. They are just magic identifiers. Think of the implementation: switch(tok.ident) { case Id::safe: case Id::property: // etc for built ins default: // handle user ones here } If you were to define a struct safe {}, which is perfectly legal D, and try to use it, you won't get what you expect. It will trigger the case safe before it goes to the default. So, the user defined one will just be quietly hidden.
Apr 06 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Friday, 6 April 2012 at 15:16:37 UTC, Piotr Szturmaj wrote:
 __traits(getAttributes, x)

Note that my proposal from a couple weeks ago did it this way. getAttributes returned a TypeTuple. You'd loop through it with is(typeof()) to extract a specific one. The key is the type name. The value is whatever your thing evaluated to: attr(10+2) decl; conceptually the same as enum tmp = 10+2; decl.annotations ~= tmp;
Apr 06 2012
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 06 Apr 2012 11:00:25 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 On 4/6/12 5:06 AM, Walter Bright wrote:
 On 4/6/2012 2:41 AM, Johannes Pfau wrote:
 The last time custom attributes where discussed, a C# like model was
 proposed. Is there a good reason why we should deviate from the C#
 implementation?

C# uses a runtime implementation, not a compile time one.

Speaking of the distinction, it would be great if we arranged things such that attributes are a lowering to existing D (i.e. the compiler rewrites a nice attribute syntax into clunky D code you wouldn't want to write by hand). Lowerings have worked miracles for us in terms of keeping language semantics simple and reducing implementation bugs. We should use them wherever appropriate.

I don't think that applies here. We have no low-level mechanism to affect the compiler internals, which is where attribute metadata belongs. -Steve
Apr 06 2012
prev sibling next sibling parent Marco Leise <Marco.Leise gmx.de> writes:
I don't want this thread to disappear. The ideas presented here have common=
 basic features among the nice-to-haves.

1. Attributes add meta data baggage to a symbol
2. This meta data is thought of as a read-only hash (has, get, iterate)
3. Can be queried at compile-time
4. The syntax is concise (i.e. improves over implementing attributes 'manua=
lly' with mixins)

Now the compiler has solved things (what is a symbol, an AST, ...) in one s=
pecific way and to keep it stable and the amount of work within bounds, any=
 implementation details of attributes that make invasive changes necessary =
should be postponed. I don't know the compiler, so it is just my gut feelin=
g when I say that annotating local variables could be a refinement to 1) th=
at doesn't work well. You get the point.

With that in mind it would be good to know exactly what can simply be tacke=
d onto the front-end (rather than refactoring a complex part of it). "What =
do you want to hear?" I hear you ask. Ok, here is my shameless "since D is =
supposed to be" argument: D is supposed to be pragmatic, so I would start w=
ith a collection of use cases. Really, "I want attributes to be like this" =
is not enough. The use case should be stated in a fashion, that programmers=
 without experience in the field can follow. The standard use cases for att=
ributes are must-haves, the rest can be nice-to-haves.

Add to the list, what you need from the attribute system:

** Serialization/RPC **

A relational SQL database comes with meta information on data types. We wan=
t to annotate D types with the corresponding types in the DB. This can be u=
sed to validate the value ranges at runtime, generate the correct SQL to wo=
rk with the tables or even create tables that don't exist already. It is al=
so common to establish relations between tables. The struct Parent may have=
 a 'Child*[]' field and Child a 'Parent*' field.
The same applies to RPC. For example we may want to return a bool[] using a=
 special case in the RPC system for bit arrays: ' Rpc(type =3D RpcType.nati=
ve_bit_array, mode =3D RpcMode.async) bool[] foo() { =E2=80=A6 }'. This ann=
otation applies to the symbol foo. If make this a more complex return type,=
 it becomes this:

	enum RpcMode =E2=80=A6;
	enum RpcType =E2=80=A6;

	struct Rpc =E2=80=A6;
	struct RpcStruct =E2=80=A6;
	// has a single field, syntax options:
	//  RpcTypeMap(type =3D RpcType.int)
	//  RpcTypeMap(RpcType.int)
	//  RpcTypeMap(int) ?
	struct RpcTypeMod { RpcType type };

	 RpcStruct struct MyRet {
		string name;
		 RpcTypeMap(RpcType.native_bit_array) bool[] flags;
	}

	 Rpc(mode =3D RpcMode.async) MyRet foo() { =E2=80=A6 }

For RPC it is also necessary, to annotate parameters in the same way:

	void foo( RpcTypeMap(RpcType.native_bit_array) bool[] flags) { =E2=80=A6 }


** Edit object properties in a GUI (as suggested by Manu) **

As seen in GUI builders, often the need occurs to generate bindings to data=
 structures in order to edit their properties in a convenient user interfac=
e. A uint field may be edited using a RGB+Alpha color selector and serializ=
ed into a data file. The requirements for the annotations are the same as a=
bove. (I know that RTTI would make life easier here, but it isn't a show st=
opper.)



For these to work it would require:
- user annotations to functions/methods/structs/classes
- only CTFE support (as annotations don't change at runtime)
- no influence on language semantics
And I agree with others that it is a good idea to implement annotations as =
structured types (POD structs at least) to avoid spelling mistakes and enco=
urage IDE support. Just as an idea: Such structs, could contain their own l=
ogic. So some annotations which work stand-alone could validate themselves =
(invariant()?), print debug msgs, write binding definitions to text files (=
if CTFE I/O happens) or actually mixin code if used on structs/classes. But=
 that's just brain-storming to give an idea why annotations as key/value pa=
irs could be unflexible.
Generally C# and Java annotations have both been a success, so they are bot=
h what people mostly expect and a good 'template' for D aside from runtim v=
s. compile-time issues.

thanks for reading :)

--=20
Marco
Apr 08 2012
prev sibling next sibling parent Marco Leise <Marco.Leise gmx.de> writes:
Am Sun, 08 Apr 2012 12:44:17 +0200
schrieb Jacob Carlborg <doob me.com>:

 On 2012-04-08 09:27, Marco Leise wrote:
 I don't want this thread to disappear. The ideas presented here have common
basic features among the nice-to-haves.

 For these to work it would require:
 - user annotations to functions/methods/structs/classes
 - only CTFE support (as annotations don't change at runtime)

I don't see why the attributes should be accessible at runtime. Even if they're read-only it's still good to be able to read the attributes at runtime.

Yeah, it was supposed to mean "it requires CTFE support, runtime support is possible" :) -- Marco
Apr 08 2012
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 10 Apr 2012 06:32:00 -0400, Timon Gehr <timon.gehr gmx.ch> wrote:

 On 04/10/2012 12:18 AM, Walter Bright wrote:

 But you said it was added to the *type*.

What I said was that it is added to the declaration. If the declaration happens to declare a type, then that must affect the type: attr(foo) struct Foo{} // annotate 'foo' attr(bar) Foo x; __traits(getAttributes, typeof(x)); // this will find 'foo', but no 'bar' __traits(getAttributes, x); // this will find 'bar', but not 'foo'

I should clarify that it's *associated* with the type. It should not affect the type in how it functions, at all. For all usages of Foo except to get attributes associated with its declaration, it should be treated as if it doesn't have an attribute on it. So it doesn't affect how the type operates or how it's matched, etc. except in the capacity that you query its attributes. -Steve
Apr 10 2012
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 10 Apr 2012 02:30:21 -0400, Jacob Carlborg <doob me.com> wrote:

 On 2012-04-09 23:49, deadalnix wrote:

 If it is available at compile time, it is implementable at runtime as a
 lib. So you pay for it only if you use it, and you don't add feature in
 the language just because it is convenient.

I'm not saying how it should be implemented, just that it should be accessible at runtime.

I think there was some confusion, read a quote of what you said: "I don't see why the attributes *should* be accessible at runtime" Emphasis added. I think you meant "shouldn't" -Steve
Apr 10 2012
prev sibling parent Marco Leise <Marco.Leise gmx.de> writes:
Am Tue, 10 Apr 2012 13:53:09 +0200
schrieb Jacob Carlborg <doob me.com>:

 On 2012-04-10 13:41, Steven Schveighoffer wrote:
 On Tue, 10 Apr 2012 02:30:21 -0400, Jacob Carlborg <doob me.com> wrote:

 On 2012-04-09 23:49, deadalnix wrote:

 If it is available at compile time, it is implementable at runtime as a
 lib. So you pay for it only if you use it, and you don't add feature in
 the language just because it is convenient.

I'm not saying how it should be implemented, just that it should be accessible at runtime.

I think there was some confusion, read a quote of what you said: "I don't see why the attributes *should* be accessible at runtime" Emphasis added. I think you meant "shouldn't" -Steve

Yeah, I did, hehe :) This thread is getting too long now.

So in the end we more or less agree that Walter and others can implement useful attributes for compile-time, whereas runtime support is nice-to-have (or can be provided by a lib)? My intention is to make it easier for the one who implements them if runtime support proves difficult. -- Marco
Apr 10 2012