Re: Should pure nothrow --- @pure @nothrow ?
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. This is not correct. For example in C# you have the Flags attribute for 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. I also think that the huge body of C++, Java, C# (and even D!) code sets 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=attributesr=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.
Re: Should pure nothrow --- @pure @nothrow ?
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.
Re: Should pure nothrow --- @pure @nothrow ?
Fri, 27 Nov 2009 14:10:34 +0100, Danny Wilson wrote: Op Fri, 27 Nov 2009 11:58:59 +0100 schreef Don nos...@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 { ... } Nice work, now you don't need to imagine it anymore.
Re: Should pure nothrow --- @pure @nothrow ?
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
Re: Should pure nothrow --- @pure @nothrow ?
Definitely. And what about @deprecated and @override? As override is now required, i don't think it should be an attribute.
Re: Should pure nothrow --- @pure @nothrow ?
#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.
Re: Should pure nothrow --- @pure @nothrow ?
On Fri, 27 Nov 2009 12:09:05 +0300, Don nos...@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.
Re: Should pure nothrow --- @pure @nothrow ?
On Fri, 27 Nov 2009 12:30:30 +0300, Lars T. Kyllingstad pub...@kyllingen.nospamnet wrote: Denis Koroskin wrote: On Fri, 27 Nov 2009 12:09:05 +0300, Don nos...@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.
Re: Should pure nothrow --- @pure @nothrow ?
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
Re: Should pure nothrow --- @pure @nothrow ?
On Fri, 27 Nov 2009 12:50:19 +0300, bearophile bearophileh...@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
Re: Should pure nothrow --- @pure @nothrow ?
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
Re: Should pure nothrow --- @pure @nothrow ?
On Fri, 27 Nov 2009 13:58:59 +0300, Don nos...@nospam.com wrote: Denis Koroskin wrote: On Fri, 27 Nov 2009 12:50:19 +0300, bearophile bearophileh...@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!
Re: Should pure nothrow --- @pure @nothrow ?
On Fri, 27 Nov 2009 13:56:10 +0300, Lars T. Kyllingstad pub...@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 { // ... }
Re: Should pure nothrow --- @pure @nothrow ?
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 cont! rol can lock on these objects as well, which can cause race conditions and other nasty threading-related bugs. Bye, bearophile
Re: Should pure nothrow --- @pure @nothrow ?
Denis Koroskin wrote: On Fri, 27 Nov 2009 13:58:59 +0300, Don nos...@nospam.com wrote: Denis Koroskin wrote: On Fri, 27 Nov 2009 12:50:19 +0300, bearophile bearophileh...@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!
Re: Should pure nothrow --- @pure @nothrow ?
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.
Re: Should pure nothrow --- @pure @nothrow ?
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
Re: Should pure nothrow --- @pure @nothrow ?
Op Fri, 27 Nov 2009 11:58:59 +0100 schreef Don nos...@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 { ... }
Re: Should pure nothrow --- @pure @nothrow ?
Denis Koroskin, el 27 de noviembre a las 12:17 me escribiste: On Fri, 27 Nov 2009 12:09:05 +0300, Don nos...@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
Re: Should pure nothrow --- @pure @nothrow ?
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. This is not correct. For example in C# you have the Flags attribute for 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.
Re: Should pure nothrow --- @pure @nothrow ?
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. This is not correct. For example in C# you have the Flags attribute for 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. I also think that the huge body of C++, Java, C# (and even D!) code sets 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.
Re: Should pure nothrow --- @pure @nothrow ?
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
Re: Should pure nothrow --- @pure @nothrow ?
On Fri, 27 Nov 2009 03:18:05 +0300, Don nos...@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).
Re: Should pure nothrow --- @pure @nothrow ?
Denis Koroskin wrote: On Fri, 27 Nov 2009 03:18:05 +0300, Don nos...@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.
Re: Should pure nothrow --- @pure @nothrow ?
== Quote from Don (nos...@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.