www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Should pure nothrow ---> pure nothrow ?

reply Don <nospam nospam.com> writes:
It seems that pure and nothrow are attributes, just like  safe.
(By contrast, you can overload functions based on const and immutable).
Should the names be changed?
Nov 26 2009
next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Fri, 27 Nov 2009 03:18:05 +0300, Don <nospam nospam.com> wrote:


 It seems that pure and nothrow are attributes, just like  safe.
 (By contrast, you can overload functions based on const and immutable).
 Should the names be changed?


I agree. I also believe there should be  naked (it's somewhat unintuitive  
that asm { naked; } anywhere withing function body makes it naked).
Nov 26 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Denis Koroskin wrote:

 On Fri, 27 Nov 2009 03:18:05 +0300, Don <nospam nospam.com> wrote:
 

 It seems that pure and nothrow are attributes, just like  safe.
 (By contrast, you can overload functions based on const and immutable).
 Should the names be changed?


 
 I agree. I also believe there should be  naked (it's somewhat 
 unintuitive that asm { naked; } anywhere withing function body makes it 
 naked).


Naked is not an externally visible attribute of a function, signature or 
  type, it only concerns the internals. Therefore, it shouldn't be an 
attribute.
Nov 26 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:

 Naked is not an externally visible attribute of a function, signature or 
   type, it only concerns the internals. Therefore, it shouldn't be an 
 attribute.


On the other hand I agree with them that currently "naked" is not in the best
place. So let's try another alternative:

void foo() {
   naked asm {
    ...
  }
}

(To do that attributes have to be usable inside functions too).

Bye,
bearophile
Nov 27 2009
parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Fri, 27 Nov 2009 12:50:19 +0300, bearophile <bearophileHUGS lycos.com>  
wrote:


 Walter Bright:

 Naked is not an externally visible attribute of a function, signature or
   type, it only concerns the internals. Therefore, it shouldn't be an
 attribute.


 On the other hand I agree with them that currently "naked" is not in the  
 best place. So let's try another alternative:

 void foo() {
    naked asm {
     ...
   }
 }


No, it applies  naked to an asm block, which is misleading: naked should  
be applied to the whole function body. More like

void foo()
 naked body
{
    // ...
}

But I still prefer  naked void foo();, especially since there was a  
movement towards drop of body keyword (see My Body Is Ugly thread).


 (To do that attributes have to be usable inside functions too).

 Bye,
 bearophile
Nov 27 2009
parent reply Don <nospam nospam.com> writes:
Denis Koroskin wrote:

 On Fri, 27 Nov 2009 12:50:19 +0300, bearophile 
 <bearophileHUGS lycos.com> wrote:
 

 Walter Bright:

 Naked is not an externally visible attribute of a function, signature or
   type, it only concerns the internals. Therefore, it shouldn't be an
 attribute.


 On the other hand I agree with them that currently "naked" is not in 
 the best place. So let's try another alternative:

 void foo() {
    naked asm {
     ...
   }
 }


 
 No, it applies  naked to an asm block, which is misleading: naked should 
 be applied to the whole function body. 


Yes, but if a function is naked, it should be illegal for it to contain 
any non-asm executable code. The compiler can't generate correct code 
when it's in a naked function. For all it knows, the function might even 
have swapped stack pointers!

I believe D is quite correct in making 'naked' an asm instruction. Not 
all CPUs might support it. (It's only relevant for CPUs/compilers where 
a frame pointer is used).


 void foo()
  naked body
 {


LOL! Spam filters would love that!!
Nov 27 2009
next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Fri, 27 Nov 2009 13:58:59 +0300, Don <nospam nospam.com> wrote:


 Denis Koroskin wrote:

 On Fri, 27 Nov 2009 12:50:19 +0300, bearophile  
 <bearophileHUGS lycos.com> wrote:


 Walter Bright:

 Naked is not an externally visible attribute of a function, signature  
 or
   type, it only concerns the internals. Therefore, it shouldn't be an
 attribute.


 On the other hand I agree with them that currently "naked" is not in  
 the best place. So let's try another alternative:

 void foo() {
    naked asm {
     ...
   }
 }


  No, it applies  naked to an asm block, which is misleading: naked  
 should be applied to the whole function body.


 Yes, but if a function is naked, it should be illegal for it to contain  
 any non-asm executable code. The compiler can't generate correct code  
 when it's in a naked function. For all it knows, the function might even  
 have swapped stack pointers!


I definitely saw code that uses D inside naked functions (and wrote such
code myself). There is an example in  
src/druntime/src/compiler/dmd/rt/trace.d
I agree it might not be portable, but so is any code written in asm.

In fact, I'm using naked to make code /more portable/ in my DynamicCall
module:

void push(T)(T arg)    // pass an argument to a function however compiler
                        // wants (e.g. pass argument in EAX, if it fits)
{
       asm { naked; ret; }
}

void invokeFunction(void* funcptr, Arg arg)
{
       switch (arg.type) {
           case ArgType.Float:
               // so that I don't care how exactly floating-point variables
               // are passed to function, let compiler do it for me
               push!(float)(*cast(float*)arg.ptr);
               break;
           ...
       }

       asm { call funcptr; }
}

(This is a simplified code for a single-argument function call)

I'm not sure how correct it is, though (I asked for a comment but no one  
answered).


 I believe D is quite correct in making 'naked' an asm instruction. Not  
 all CPUs might support it. (It's only relevant for CPUs/compilers where  
 a frame pointer is used).


Sure, but it only makes naked a vendor-specific extension, it doesn't make
it illegal to use. Since it's not a user-defined annotation those  
compilers that don't support would just issue a compile-time error (the  
same way they would do it for asm { naked; } so it's just a matter of  
syntax). I prefer it to be an annotation because it's not an asm  
instruction at all. It has a lot in common with extern (Foo), so I'd like  
for them share syntax, too ( extern(C) void* malloc(size_t size); ?)


 void foo()
  naked body
 {


 LOL! Spam filters would love that!!


Indeed!
Nov 27 2009
parent Don <nospam nospam.com> writes:
Denis Koroskin wrote:

 On Fri, 27 Nov 2009 13:58:59 +0300, Don <nospam nospam.com> wrote:
 

 Denis Koroskin wrote:

 On Fri, 27 Nov 2009 12:50:19 +0300, bearophile 
 <bearophileHUGS lycos.com> wrote:


 Walter Bright:

 Naked is not an externally visible attribute of a function, 
 signature or
   type, it only concerns the internals. Therefore, it shouldn't be an
 attribute.


 On the other hand I agree with them that currently "naked" is not in 
 the best place. So let's try another alternative:

 void foo() {
    naked asm {
     ...
   }
 }


  No, it applies  naked to an asm block, which is misleading: naked 
 should be applied to the whole function body.


 Yes, but if a function is naked, it should be illegal for it to 
 contain any non-asm executable code. The compiler can't generate 
 correct code when it's in a naked function. For all it knows, the 
 function might even have swapped stack pointers!


 
 I definitely saw code that uses D inside naked functions (and wrote such
 code myself). There is an example in 
 src/druntime/src/compiler/dmd/rt/trace.d
 I agree it might not be portable, but so is any code written in asm.


Thanks, that one should be changed. It's just a call to a void function, 
and should be changed to a single call instruction. It wouldn't compile 
in LDC.


 In fact, I'm using naked to make code /more portable/ in my DynamicCall
 module:
 
 void push(T)(T arg)    // pass an argument to a function however compiler
                        // wants (e.g. pass argument in EAX, if it fits)
 {
       asm { naked; ret; }
 }
 
 void invokeFunction(void* funcptr, Arg arg)
 {
       switch (arg.type) {
           case ArgType.Float:
               // so that I don't care how exactly floating-point variables
               // are passed to function, let compiler do it for me
               push!(float)(*cast(float*)arg.ptr);
               break;
           ...
       }
 
       asm { call funcptr; }
 }
 
 (This is a simplified code for a single-argument function call)
 
 I'm not sure how correct it is, though (I asked for a comment but no one 
 answered).


That doesn't involve any mixing of naked and D in a single function. Of 
course, your 'push' function leaves the stack in a corrupt state. 
Definitely an unsafe function!


 I believe D is quite correct in making 'naked' an asm instruction. Not 
 all CPUs might support it. (It's only relevant for CPUs/compilers 
 where a frame pointer is used).


 
 Sure, but it only makes naked a vendor-specific extension, it doesn't make
 it illegal to use. Since it's not a user-defined annotation those 
 compilers that don't support would just issue a compile-time error (the 
 same way they would do it for asm { naked; } so it's just a matter of 
 syntax). I prefer it to be an annotation because it's not an asm 
 instruction at all. It has a lot in common with extern (Foo), so I'd 
 like for them share syntax, too ( extern(C) void* malloc(size_t size); ?)


It's absolutely none of the caller's business whether the function is 
naked. Naked has no consequences outside of the function body.




 void foo()
  naked body
 {


 LOL! Spam filters would love that!!


 
 Indeed!
Nov 27 2009
prev sibling parent "Danny Wilson" <bluezenix gmail.com> writes:
Op Fri, 27 Nov 2009 11:58:59 +0100 schreef Don <nospam nospam.com>:


 void foo()
  naked body
 {


 LOL! Spam filters would love that!!


I can already imagine the jokes spreading over the internets:

 safe public double penetration(of a)  naked body { ... }
Nov 27 2009
prev sibling next sibling parent dsimcha <dsimcha yahoo.com> writes:
== Quote from Don (nospam nospam.com)'s article

 It seems that pure and nothrow are attributes, just like  safe.
 (By contrast, you can overload functions based on const and immutable).
 Should the names be changed?


Vote++.  Now that we have attributes, I think this is a no brainer from a
consistency perspective.
Nov 26 2009
prev sibling next sibling parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
Don wrote:

 It seems that pure and nothrow are attributes, just like  safe.
 (By contrast, you can overload functions based on const and immutable).
 Should the names be changed?


Definitely. And what about  deprecated and  override?

-Lars
Nov 27 2009
prev sibling next sibling parent reply #ponce <aliloko gmail.com> writes:
 
 Definitely. And what about  deprecated and  override?


As override is now required, i don't think it should be an attribute.
Nov 27 2009
parent reply Don <nospam nospam.com> writes:
#ponce wrote:

 Definitely. And what about  deprecated and  override?


 
 As override is now required, i don't think it should be an attribute.


As I understand it, one of the characteristics of attributes is that you 
should be able to remove them from the entire program, without affecting 
the behaviour.  All they are doing is adding additional compile-time 
constraints. (const and immutable aren't attributes, because you're 
allowed to overload functions based on them).

So  deprecated is definitely an attribute.

Is override really required? I've just tested on DMD2.037, and it still 
accepts functions without it. So at present it is behaving like an 
attribute. But if it became mandatory, I'm not so sure.
Nov 27 2009
next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Fri, 27 Nov 2009 12:09:05 +0300, Don <nospam nospam.com> wrote:


 #ponce wrote:

 Definitely. And what about  deprecated and  override?


  As override is now required, i don't think it should be an attribute.


 As I understand it, one of the characteristics of attributes is that you  
 should be able to remove them from the entire program, without affecting  
 the behaviour.  All they are doing is adding additional compile-time  
 constraints. (const and immutable aren't attributes, because you're  
 allowed to overload functions based on them).

 So  deprecated is definitely an attribute.

 Is override really required? I've just tested on DMD2.037, and it still  
 accepts functions without it. So at present it is behaving like an  
 attribute. But if it became mandatory, I'm not so sure.


override is required when compiling with -w.

By Walter's definition,  property is not a valid attribute, because by  
removing it the program will fail to compile (due to missing parens in  
accessors). Either that or omissible empty parens will still be present,  
but I see no usefulness of  property in that case.
Nov 27 2009
next sibling parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
Denis Koroskin wrote:

 On Fri, 27 Nov 2009 12:09:05 +0300, Don <nospam nospam.com> wrote:
 

 #ponce wrote:

 Definitely. And what about  deprecated and  override?


  As override is now required, i don't think it should be an attribute.


 As I understand it, one of the characteristics of attributes is that 
 you should be able to remove them from the entire program, without 
 affecting the behaviour.  All they are doing is adding additional 
 compile-time constraints. (const and immutable aren't attributes, 
 because you're allowed to overload functions based on them).

 So  deprecated is definitely an attribute.

 Is override really required? I've just tested on DMD2.037, and it 
 still accepts functions without it. So at present it is behaving like 
 an attribute. But if it became mandatory, I'm not so sure.


 
 override is required when compiling with -w.
 
 By Walter's definition,  property is not a valid attribute, because by 
 removing it the program will fail to compile (due to missing parens in 
 accessors). Either that or omissible empty parens will still be present, 
 but I see no usefulness of  property in that case.


But it still doesn't affect the generated binary code, and I think 
that's the important part here.

     property void foo(int i) { ... }
    foo = 7;

generates the exact same code as

    void foo(int i) { ... }
    foo(7);

We need a definition of attributes/annotations that is a bit wider than 
"can be removed from program without anything happening". Denis' example 
clearly demonstrates this.

Something in the vein of "annotations only provide additional 
information and constraints for the compiler, and do not affect the 
generated code" would be better.

-Lars
Nov 27 2009
parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Fri, 27 Nov 2009 12:30:30 +0300, Lars T. Kyllingstad  
<public kyllingen.nospamnet> wrote:


 Denis Koroskin wrote:

 On Fri, 27 Nov 2009 12:09:05 +0300, Don <nospam nospam.com> wrote:


 #ponce wrote:

 Definitely. And what about  deprecated and  override?


  As override is now required, i don't think it should be an attribute.


 As I understand it, one of the characteristics of attributes is that  
 you should be able to remove them from the entire program, without  
 affecting the behaviour.  All they are doing is adding additional  
 compile-time constraints. (const and immutable aren't attributes,  
 because you're allowed to overload functions based on them).

 So  deprecated is definitely an attribute.

 Is override really required? I've just tested on DMD2.037, and it  
 still accepts functions without it. So at present it is behaving like  
 an attribute. But if it became mandatory, I'm not so sure.


  override is required when compiling with -w.
  By Walter's definition,  property is not a valid attribute, because by  
 removing it the program will fail to compile (due to missing parens in  
 accessors). Either that or omissible empty parens will still be  
 present, but I see no usefulness of  property in that case.


 But it still doesn't affect the generated binary code, and I think  
 that's the important part here.

      property void foo(int i) { ... }
     foo = 7;

 generates the exact same code as

     void foo(int i) { ... }
     foo(7);

 We need a definition of attributes/annotations that is a bit wider than  
 "can be removed from program without anything happening". Denis' example  
 clearly demonstrates this.

 Something in the vein of "annotations only provide additional  
 information and constraints for the compiler, and do not affect the  
 generated code" would be better.

 -Lars


I think "do not affect the generated code" is a bit restricting. I see  
attributes as hints to compiler (especially since there is no way to use  
user-defined attributes). Compiler may understand and make use of some of  
them. For example, I'd like to be able to annotate a function as  
 thread-safe, and hope that a smart compiler will optimize my code based  
on that information (it doesn't mean it have to). Other example is that  
I'd like for some functions to leave all bounds checks (even in -release)  
without making it  safe. Or profile this concrete method. Or exclude this  
concrete method from profiling. There are endless possibilities.

Some of this attributes might be vendor-specific, they should probably  
start with a double-underscore (e.g.  __naked).

That's the way I see attributes.
Nov 27 2009
parent bearophile <bearophileHUGS lycos.com> writes:
Denis Koroskin:


 I think "do not affect the generated code" is a bit restricting.
 [...] There are endless possibilities.


Lombok gives annotations to reduce boring lines of Java code:
http://projectlombok.org/features/index.html

Some of those annotations:
 Getter /  Setter: Never write public int getFoo() {return foo;} again.

 ToString: No need to start a debugger to see your fields: Just let lombok
generate a toString for you! (I think this can be automatic for D structs).

 EqualsAndHashCode: Equality made easy: Generates hashCode and equals
implementations from the fields of your object.

 Synchronized: synchronized done right: Don't expose your locks.

More info on the  Synchronized:

 Synchronized is a safer variant of the synchronized method modifier. Like
synchronized, the annotation can be used on static and instance methods only.
It operates similarly to the synchronized keyword, but it locks on different
objects. The keyword locks on this, but the annotation locks on a field named
$lock, which is private. If the field does not exist, it is created for you. If
you annotate a static method, the annotation lo cks on a static field named
$LOCK instead. If you want, you can create these locks yourself. The $lock and
$LOCK fields will of course not be generated if you already created them
yourself. You can also choose to lock on another field, by specifying it as
parameter to the  Synchronized annotation. In this usage variant, the fields
will not be created automatically, and you must explicitly create them
yourself, or an error will be emitted. Locking on this or your own class object
can have unfortunate side-effects, as other code not under your control can
lock on these objects as well, which can cause race conditions and other nasty
threading-related bugs.<


Bye,
bearophile
Nov 27 2009
prev sibling parent Leandro Lucarella <llucax gmail.com> writes:
Denis Koroskin, el 27 de noviembre a las 12:17 me escribiste:

 On Fri, 27 Nov 2009 12:09:05 +0300, Don <nospam nospam.com> wrote:
 

#ponce wrote:

Definitely. And what about  deprecated and  override?


 As override is now required, i don't think it should be an attribute.


As I understand it, one of the characteristics of attributes is
that you should be able to remove them from the entire program,
without affecting the behaviour.  All they are doing is adding
additional compile-time constraints. (const and immutable aren't
attributes, because you're allowed to overload functions based on
them).

So  deprecated is definitely an attribute.

Is override really required? I've just tested on DMD2.037, and it
still accepts functions without it. So at present it is behaving
like an attribute. But if it became mandatory, I'm not so sure.


 
 override is required when compiling with -w.
 
 By Walter's definition,  property is not a valid attribute, because
 by removing it the program will fail to compile (due to missing
 parens in accessors). Either that or omissible empty parens will
 still be present, but I see no usefulness of  property in that case.


 deprecated will affect if a program compiles too.  safe /  trusted
/  system too. I think we need a better definition of what an annotation
is :)

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Si le decía "Vamos al cine, rica"
Me decía "Veamos una de Kusturica"
Si le decía "Vamos a oler las flores"
Me hablaba de Virginia Wolf y sus amores
Me hizo mucho mal la cumbiera intelectual
Nov 27 2009
prev sibling next sibling parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
Don wrote:

 #ponce wrote:

 Definitely. And what about  deprecated and  override?


 As override is now required, i don't think it should be an attribute.


 
 As I understand it, one of the characteristics of attributes is that you 
 should be able to remove them from the entire program, without affecting 
 the behaviour.  All they are doing is adding additional compile-time 
 constraints. (const and immutable aren't attributes, because you're 
 allowed to overload functions based on them).


If this is the rule, shouldn't the protection attributes be moved into 
the annotation namespace as well? ( private,  protected,  package, 
 public) Since everything is public by default in D, a program will keep 
working even if you remove them.

NOTE: I don't necessarily think they should, but I do think there should 
be a definite rule for which attributes are  annotations and which 
aren't. Otherwise it just seems random.

-Lars
Nov 27 2009
next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Fri, 27 Nov 2009 13:56:10 +0300, Lars T. Kyllingstad  
<public kyllingen.nospamnet> wrote:


 Don wrote:

 #ponce wrote:

 Definitely. And what about  deprecated and  override?


 As override is now required, i don't think it should be an attribute.


  As I understand it, one of the characteristics of attributes is that  
 you should be able to remove them from the entire program, without  
 affecting the behaviour.  All they are doing is adding additional  
 compile-time constraints. (const and immutable aren't attributes,  
 because you're allowed to overload functions based on them).


 If this is the rule, shouldn't the protection attributes be moved into  
 the annotation namespace as well? ( private,  protected,  package,  
  public) Since everything is public by default in D, a program will keep  
 working even if you remove them.

 NOTE: I don't necessarily think they should, but I do think there should  
 be a definite rule for which attributes are  annotations and which  
 aren't. Otherwise it just seems random.

 -Lars


A straight line needs to be drawn, or we end up with something like this:

 public  final  override  extern (Windows)  naked  deprecated  pure int  
foo() invariant
{
     // ...
}
Nov 27 2009
prev sibling parent reply Don <nospam nospam.com> writes:
Lars T. Kyllingstad wrote:

 Don wrote:

 #ponce wrote:

 Definitely. And what about  deprecated and  override?


 As override is now required, i don't think it should be an attribute.


 As I understand it, one of the characteristics of attributes is that 
 you should be able to remove them from the entire program, without 
 affecting the behaviour.  All they are doing is adding additional 
 compile-time constraints. (const and immutable aren't attributes, 
 because you're allowed to overload functions based on them).


 
 If this is the rule, shouldn't the protection attributes be moved into 
 the annotation namespace as well? ( private,  protected,  package, 
  public) Since everything is public by default in D, a program will keep 
 working even if you remove them.
 
 NOTE: I don't necessarily think they should, but I do think there should 
 be a definite rule for which attributes are  annotations and which 
 aren't. Otherwise it just seems random.
 
 -Lars


Obviously my rule isn't correct. It's hard to come up with a rule that 
includes  property, without including everything else.
Nov 27 2009
parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
Don wrote:

 Lars T. Kyllingstad wrote:

 Don wrote:

 #ponce wrote:

 Definitely. And what about  deprecated and  override?


 As override is now required, i don't think it should be an attribute.


 As I understand it, one of the characteristics of attributes is that 
 you should be able to remove them from the entire program, without 
 affecting the behaviour.  All they are doing is adding additional 
 compile-time constraints. (const and immutable aren't attributes, 
 because you're allowed to overload functions based on them).


 If this is the rule, shouldn't the protection attributes be moved into 
 the annotation namespace as well? ( private,  protected,  package, 
  public) Since everything is public by default in D, a program will 
 keep working even if you remove them.

 NOTE: I don't necessarily think they should, but I do think there 
 should be a definite rule for which attributes are  annotations and 
 which aren't. Otherwise it just seems random.

 -Lars


 
 Obviously my rule isn't correct. It's hard to come up with a rule that 
 includes  property, without including everything else.


That's what I suspected. How about saying that annotations only provide 
compile-time constraints on the body, i.e. the internals, of the 
function being annotated?

Then, the following would be annotations:

    safe,  unsafe,  system,  pure,  nothrow

while the following would have to be ordinary keywords:

   property, private, public, deprecated

-Lars
Nov 27 2009
prev sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Don wrote:

 #ponce wrote:

 Definitely. And what about  deprecated and  override?


 As override is now required, i don't think it should be an attribute.


 
 As I understand it, one of the characteristics of attributes is that you 
 should be able to remove them from the entire program, without affecting 
 the behaviour.



enums:

enum Foo {
   One = 1,
   Two = 2,
   Three = 4,
}

You can't do:

var x = Foo.One | Foo.Two;

but if you do:

[Flags]
enum Foo { ... }

you can do it now.

Also see this: 
http://msdn.microsoft.com/en-us/library/system.flagsattribute(VS.71).aspx

Removing the Flags attribute changes program behaviour. An attribute, 
indeed, tells someone (the compiler, the programmer, an external tool) 
that a symbol has some attribute. It could change the program if the 
compiler is the one using that attribute. So in theory every attribute 
in D could be an  attribute.
Nov 27 2009
parent reply Don <nospam nospam.com> writes:
Ary Borenszweig wrote:

 Don wrote:

 #ponce wrote:

 Definitely. And what about  deprecated and  override?


 As override is now required, i don't think it should be an attribute.


 As I understand it, one of the characteristics of attributes is that 
 you should be able to remove them from the entire program, without 
 affecting the behaviour.


 

 enums:
 
 enum Foo {
   One = 1,
   Two = 2,
   Three = 4,
 }
 
 You can't do:
 
 var x = Foo.One | Foo.Two;
 
 but if you do:
 
 [Flags]
 enum Foo { ... }
 
 you can do it now.
 
 Also see this: 
 http://msdn.microsoft.com/en-us/library/system.flagsattribute(VS.71).aspx
 
 Removing the Flags attribute changes program behaviour. An attribute, 
 indeed, tells someone (the compiler, the programmer, an external tool) 
 that a symbol has some attribute. It could change the program if the 
 compiler is the one using that attribute. So in theory every attribute 
 in D could be an  attribute.


Interesting. I think if we go to that extreme, the annotations would 
just end up being keywords, but slightly uglier.
It seems clear that if  safe is an annotation, then  pure and  nothrow 
are, too.


a precedent that public, protected, extern, and private should not be 
annotations -- I'd suggest that if it is a keyword in C or C++, it 
should not be an annotation. (Although that would make align a keyword, 
not an annotation, though it'd otherwise be a candidate).

Beyond that, I'm not really sure. I'd tentatively go for  deprecated, 
and  property seems to have been decided, but for override -- no idea.
Nov 27 2009
parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Don wrote:


 Ary Borenszweig wrote:

 Don wrote:

 #ponce wrote:

 Definitely. And what about  deprecated and  override?


 As override is now required, i don't think it should be an attribute.


 As I understand it, one of the characteristics of attributes is that
 you should be able to remove them from the entire program, without
 affecting the behaviour.


 

 enums:
 
 enum Foo {
   One = 1,
   Two = 2,
   Three = 4,
 }
 
 You can't do:
 
 var x = Foo.One | Foo.Two;
 
 but if you do:
 
 [Flags]
 enum Foo { ... }
 
 you can do it now.
 
 Also see this:
 http://msdn.microsoft.com/en-us/library/system.flagsattribute(VS.71).aspx
 
 Removing the Flags attribute changes program behaviour. An attribute,
 indeed, tells someone (the compiler, the programmer, an external tool)
 that a symbol has some attribute. It could change the program if the
 compiler is the one using that attribute. So in theory every attribute
 in D could be an  attribute.


 
 Interesting. I think if we go to that extreme, the annotations would
 just end up being keywords, but slightly uglier.
 It seems clear that if  safe is an annotation, then  pure and  nothrow
 are, too.
 

 a precedent that public, protected, extern, and private should not be
 annotations -- I'd suggest that if it is a keyword in C or C++, it
 should not be an annotation. (Although that would make align a keyword,
 not an annotation, though it'd otherwise be a candidate).
 
 Beyond that, I'm not really sure. I'd tentatively go for  deprecated,
 and  property seems to have been decided, but for override -- no idea.
 


In practice attributes in .NET are used for even more than that. A lot of 
API's seems to use them to provide features which could have been in code. 
Take nunit for example, it defines about 35 attributes to provide 
information about unittests. In a previous version this was done by naming 
convention and inheritance: 
http://www.nunit.org/index.php?p=attributes&r=2.5.2

I tend to think attributes in .NET are a regular means of abstraction, much 
like classes or generics. In part, they make up for lack of other 
metaprogramming features in some .NET languages.
Nov 28 2009
parent grauzone <none example.net> writes:
Lutger wrote:

 I tend to think attributes in .NET are a regular means of abstraction, much 
 like classes or generics. In part, they make up for lack of other 
 metaprogramming features in some .NET languages.


I agree; I think they are best for associating arbitrary information 
with arbitrary types or type members. I'm still hoping D will get user 
defined annotations some day in the future. I claim that they will be 
very useful for metaprogramming (at compile- and runtime). You wouldn't 
have to go roundabout ways to associate additional information to e.g. 
struct members.

Especially I'm hoping that Walter doesn't mistake annotations for just a 
separate keywords namespace.
Nov 28 2009
prev sibling parent Chad J <chadjoan __spam.is.bad__gmail.com> writes:
Don wrote:

 It seems that pure and nothrow are attributes, just like  safe.
 (By contrast, you can overload functions based on const and immutable).
 Should the names be changed?


This runs into another issue I was thinking about.

So I'm working on this property rewrite thing that does the following:

foo.prop.func();

becomes

auto t = foo.prop;
t.func();
foo.prop = t.func();

This of course assumes that calling t.func() will mutate t.  But, as I
understand it, pure member functions can't mutate their aggregates.  So
if func() was pure, then foo.prop.func() shouldn't be rewritten, and the
setter for prop should never be called.

This would mean that pure would change the behavior of a program.  Now,
if attributes are not allowed to change the behavior of a program and
property expressions are rewritten correctly, then  pure would
contradict itself.

Note: This has less to do with pure itself, and more to do with the idea
that pure functions only work with immutable data.  The property
rewriting couldn't care less whether or not the function is
deterministic, but it does care about whether or not a function's
arguments are lvalues (ex: ref parameters), including the hidden
argument containing the aggregate in method calls.

For a (slightly) more concrete example of why this matters:

import std.stdio;

struct IntProxy
{
    int data;

    pure IntProxy opAdd(IntProxy other)
    {
    IntProxy ip;
    ip.data = data + other.data;
        return ip;
    }

    IntProxy opAddAssign(IntProxy other)
    {
        this.data++;
        return this;
    }
}

class Foo
{
    IntProxy bar;
    IntProxy prop() { return bar; }
}

void main()
{
    Foo foo = new Foo();
    IntProxy ip;

    foo.bar.data = 2;
    ip.data = 2;

    IntProxy result = foo.prop + ip;

    assert(result.data == 4);
    writefln("%s",result.data);
}

I expect this program to compile, run, and print "4".

If pure were an annotation AND annotations couldn't change program
behavior AND property expression rewrite were in place, then this
program would fail to compile because there is no corresponding setter
function for foo.prop.  Due to annotations being passive, this requires
the compiler to ignore the pure status of IntProxy.opAdd and treat it
like any other impure function for purposes of property rewriting.  The
setter would then be needed to receive the possibly mutated IntProxy
returned by prop.opAdd(ip).

- Chad
Nov 27 2009