www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Negation of attributes (DIP 79)

reply "Daniel Kozak" <kozzi11 gmail.com> writes:
I am working on dip which will try to addressed negation of 
attributes issue.
http://wiki.dlang.org/DIP79
Jun 02 2015
next sibling parent reply "Liam McSherry" <mcsherry.liam gmail.com> writes:
In the examples you give, you could surround the final methods in 
a final block. Testing with dmd 2.067.1, the following works:

---
class C
{
     final
     {
         void nonOverrideable()
         {
             "Hello, World!".writeln;
         }
     }

     bool overrideable()
     {
         return true;
     }
}

class D : C
{
     override void nonOverrideable() // Error
     {
         "Goodbye!".writeln;
     }

     override bool overrideable() // No error
     {
         return false;
     }
}
---

To me, at least, it's also more intuitive than "!final:".
Jun 02 2015
parent reply "Namespace" <rswhite4 gmail.com> writes:
On Tuesday, 2 June 2015 at 11:07:21 UTC, Liam McSherry wrote:
 In the examples you give, you could surround the final methods 
 in a final block. Testing with dmd 2.067.1, the following works:

 ---
 class C
 {
     final
     {
         void nonOverrideable()
         {
             "Hello, World!".writeln;
         }
     }

     bool overrideable()
     {
         return true;
     }
 }

 class D : C
 {
     override void nonOverrideable() // Error
     {
         "Goodbye!".writeln;
     }

     override bool overrideable() // No error
     {
         return false;
     }
 }
 ---

 To me, at least, it's also more intuitive than "!final:".
For me it looks ugly. But I would prefer final(false) instead of !final.
Jun 02 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Tue, 02 Jun 2015 11:50:15 +0000, Namespace wrote:

 For me it looks ugly. But I would prefer final(false) instead of !final.
this opens a can of worms. should this be accepted too: enum doItFinal =3D false; final(doItFinal) ? or even final(someFunnyTemplate!(with_, args, andOtherTemplate!"too")) ? =
Jun 02 2015
next sibling parent Daniel =?UTF-8?B?S296w6Fr?= via Digitalmars-d writes:
On Tue, 2 Jun 2015 12:21:23 +0000 (UTC)
ketmar via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 On Tue, 02 Jun 2015 11:50:15 +0000, Namespace wrote:
 
 For me it looks ugly. But I would prefer final(false) instead
 of !final.
this opens a can of worms. should this be accepted too: enum doItFinal = false; final(doItFinal) ? or even final(someFunnyTemplate!(with_, args, andOtherTemplate!"too")) ?
Exactly
Jun 02 2015
prev sibling next sibling parent reply "Namespace" <rswhite4 gmail.com> writes:
On Tuesday, 2 June 2015 at 12:21:23 UTC, ketmar wrote:
 On Tue, 02 Jun 2015 11:50:15 +0000, Namespace wrote:

 For me it looks ugly. But I would prefer final(false) instead 
 of !final.
this opens a can of worms. should this be accepted too: enum doItFinal = false; final(doItFinal) ? or even final(someFunnyTemplate!(with_, args, andOtherTemplate!"too")) ?
Yes, please.
Jun 02 2015
next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Tue, 02 Jun 2015 13:16:49 +0000, Namespace wrote:

 On Tuesday, 2 June 2015 at 12:21:23 UTC, ketmar wrote:
 On Tue, 02 Jun 2015 11:50:15 +0000, Namespace wrote:

 For me it looks ugly. But I would prefer final(false) instead of
 !final.
this opens a can of worms. should this be accepted too: enum doItFinal =3D false; final(doItFinal) ? or even final(someFunnyTemplate!(with_, args, andOtherTemplate!"too")) ?
=20 Yes, please.
no, please. that's terrible, that's unpredictable, that's undebugable,=20 that's slow. "we can make it dynamic" is not a good reason to actually=20 make something dynamic.=
Jun 02 2015
parent reply "Namespace" <rswhite4 gmail.com> writes:
On Tuesday, 2 June 2015 at 13:39:54 UTC, ketmar wrote:
 On Tue, 02 Jun 2015 13:16:49 +0000, Namespace wrote:

 On Tuesday, 2 June 2015 at 12:21:23 UTC, ketmar wrote:
 On Tue, 02 Jun 2015 11:50:15 +0000, Namespace wrote:

 For me it looks ugly. But I would prefer final(false) 
 instead of
 !final.
this opens a can of worms. should this be accepted too: enum doItFinal = false; final(doItFinal) ? or even final(someFunnyTemplate!(with_, args, andOtherTemplate!"too")) ?
Yes, please.
no, please. that's terrible, that's unpredictable, that's undebugable, that's slow. "we can make it dynamic" is not a good reason to actually make something dynamic.
So you dislike noexcept(condition) from C++? I like it. But no matter which syntax comes, important is that we get something to revert attributes. :)
Jun 02 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Tue, 02 Jun 2015 14:34:10 +0000, Namespace wrote:

 from C++?
that alone is enough for me to say "burn it with fire!" ;-)=
Jun 02 2015
parent reply "Namespace" <rswhite4 gmail.com> writes:
On Tuesday, 2 June 2015 at 14:46:47 UTC, ketmar wrote:
 On Tue, 02 Jun 2015 14:34:10 +0000, Namespace wrote:

 from C++?
that alone is enough for me to say "burn it with fire!" ;-)
Come on, be a little nostalgic. ;)
Jun 02 2015
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Tue, 02 Jun 2015 14:53:23 +0000, Namespace wrote:

 On Tuesday, 2 June 2015 at 14:46:47 UTC, ketmar wrote:
 On Tue, 02 Jun 2015 14:34:10 +0000, Namespace wrote:

 from C++?
that alone is enough for me to say "burn it with fire!" ;-)
=20 Come on, be a little nostalgic. ;)
that's it: i always wanted to give C++ some smelly napalm hello.=
Jun 02 2015
prev sibling parent Daniel =?UTF-8?B?S296w6Fr?= via Digitalmars-d writes:
On Tue, 02 Jun 2015 13:16:49 +0000
Namespace via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 On Tuesday, 2 June 2015 at 12:21:23 UTC, ketmar wrote:
 On Tue, 02 Jun 2015 11:50:15 +0000, Namespace wrote:

 For me it looks ugly. But I would prefer final(false) instead 
 of !final.
this opens a can of worms. should this be accepted too: enum doItFinal = false; final(doItFinal) ? or even final(someFunnyTemplate!(with_, args, andOtherTemplate!"too")) ?
Yes, please.
It would be a disaster ;-)
Jun 02 2015
prev sibling parent reply Artur Skawina via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 06/02/15 14:21, ketmar via Digitalmars-d wrote:
 On Tue, 02 Jun 2015 11:50:15 +0000, Namespace wrote:
 
 For me it looks ugly. But I would prefer final(false) instead of !final.
this opens a can of worms. should this be accepted too: enum doItFinal = false; final(doItFinal) ? or even final(someFunnyTemplate!(with_, args, andOtherTemplate!"too")) ?
[I'd assumed it was a rhetorical question, but after reading some of the followups...] Of course. Note that user defined attributes already work like that. This is a working D program, that uses GDC-specific extensions: import gcc.attribute; enum inl(alias B) = attribute(B?"forceinline":"noinline"); inl!(1) int f() { return 1; } inl!(2+2==5) int g() { return 2; } enum e = g()-f()*2; inl!e int i() { return 3; } int main() { return f()+g()+i(); } The only alternative would be to force wrapping the whole (function) definition in a mixin statement -- that is not a practical solution and not scalable at all. You end up with multiple layers of string mixins and code written inside (nested!) string literals. D has enough unnecessary special cases as it is (like built-in types being special). artur
Jun 02 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Tue, 02 Jun 2015 18:49:09 +0200, Artur Skawina via Digitalmars-d wrote:

 On 06/02/15 14:21, ketmar via Digitalmars-d wrote:
 On Tue, 02 Jun 2015 11:50:15 +0000, Namespace wrote:
=20
 For me it looks ugly. But I would prefer final(false) instead of
 !final.
=20 this opens a can of worms. should this be accepted too: enum doItFinal =3D false; final(doItFinal) ? =20 or even final(someFunnyTemplate!(with_, args, andOtherTemplate!"too")) ?
=20 [I'd assumed it was a rhetorical question, but after reading some of the followups...] =20 Of course.
this is bad. it smells. it adds almost nothing in terms of uniformity.=20 and i'm sure that Hackerpilot will be happy to know that he now needs a=20 full-blown D interpreter to determine if some method is virtual or not. ;- )=
Jun 02 2015
parent reply Artur Skawina via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 06/03/15 01:41, ketmar via Digitalmars-d wrote:
 On Tue, 02 Jun 2015 18:49:09 +0200, Artur Skawina via Digitalmars-d wrote:
 
 On 06/02/15 14:21, ketmar via Digitalmars-d wrote:
 this opens a can of worms. should this be accepted too:
   enum doItFinal = false;
   final(doItFinal)
 ?

 or even
   final(someFunnyTemplate!(with_, args, andOtherTemplate!"too"))
 ?
 Of course.
this is bad. it smells. it adds almost nothing in terms of uniformity. and i'm sure that Hackerpilot will be happy to know that he now needs a full-blown D interpreter to determine if some method is virtual or not. ;-)
An interpreter is required anyway. And that is, btw, why any simple dfix-like tool can not work with a language like D, where the *norm* is programs that write programs. artur
Jun 02 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Wed, 03 Jun 2015 02:40:55 +0200, Artur Skawina via Digitalmars-d wrote:

 On 06/03/15 01:41, ketmar via Digitalmars-d wrote:
 On Tue, 02 Jun 2015 18:49:09 +0200, Artur Skawina via Digitalmars-d
 wrote:
=20
 On 06/02/15 14:21, ketmar via Digitalmars-d wrote:
 this opens a can of worms. should this be accepted too:
   enum doItFinal =3D false;
   final(doItFinal)
 ?

 or even
   final(someFunnyTemplate!(with_, args, andOtherTemplate!"too"))
 ?
=20
 Of course.
=20 this is bad. it smells. it adds almost nothing in terms of uniformity. and i'm sure that Hackerpilot will be happy to know that he now needs a full-blown D interpreter to determine if some method is virtual or not. ;-)
=20 An interpreter is required anyway.
and the idea is still bad.=
Jun 02 2015
parent reply Kenji Hara via Digitalmars-d <digitalmars-d puremagic.com> writes:
For final, override, abstract, and synchronized attributes, I'm trying to
relax the limitation in:

https://issues.dlang.org/show_bug.cgi?id=2091
https://github.com/D-Programming-Language/dmd/pull/4714

Kenji Hara

2015-06-03 13:47 GMT+09:00 ketmar via Digitalmars-d <
digitalmars-d puremagic.com>:

 On Wed, 03 Jun 2015 02:40:55 +0200, Artur Skawina via Digitalmars-d wrote:

 On 06/03/15 01:41, ketmar via Digitalmars-d wrote:
 On Tue, 02 Jun 2015 18:49:09 +0200, Artur Skawina via Digitalmars-d
 wrote:

 On 06/02/15 14:21, ketmar via Digitalmars-d wrote:
 this opens a can of worms. should this be accepted too:
   enum doItFinal = false;
   final(doItFinal)
 ?

 or even
   final(someFunnyTemplate!(with_, args, andOtherTemplate!"too"))
 ?
 Of course.
this is bad. it smells. it adds almost nothing in terms of uniformity. and i'm sure that Hackerpilot will be happy to know that he now needs a full-blown D interpreter to determine if some method is virtual or not. ;-)
An interpreter is required anyway.
and the idea is still bad.
Jun 03 2015
parent "tcak" <tcak gmail.com> writes:
If this DIP will be accepted, please make it work for "!shared" 
as well. I don't know whether any of you has experienced though, 
in some cases, cast() doesn't remove shared attribute at all, and 
I need to write half the screen, name of same class again.
Jun 03 2015
prev sibling next sibling parent reply "ref2401" <refactor24 gmail.com> writes:
On Tuesday, 2 June 2015 at 10:29:35 UTC, Daniel Kozak wrote:
 I am working on dip which will try to addressed negation of 
 attributes issue.
 http://wiki.dlang.org/DIP79
You propose to add extra difficulty to the language and the only reason is "If you need add few methods which are virtual or variables, you are forced to put them before final:. This is too limiting.". I think it's a bad idea.
Jun 02 2015
next sibling parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Tuesday, 2 June 2015 at 12:13:47 UTC, ref2401 wrote:
 On Tuesday, 2 June 2015 at 10:29:35 UTC, Daniel Kozak wrote:
 I am working on dip which will try to addressed negation of 
 attributes issue.
 http://wiki.dlang.org/DIP79
You propose to add extra difficulty to the language and the only reason is "If you need add few methods which are virtual or variables, you are forced to put them before final:. This is too limiting.". I think it's a bad idea.
This is by far not the only reason. It is just as well useful for all other attributes: const, pure, safe/ system, nogc, and maybe UDAs. It's long been recognized that a mechanism to switch off a scope-wide attribute would be useful.
Jun 02 2015
parent reply "ref2401" <refactor24 gmail.com> writes:
 This is by far not the only reason. It is just as well useful 
 for all other attributes: const, pure,  safe/ system,  nogc, 
 and maybe UDAs.

 It's long been recognized that a mechanism to switch off a 
 scope-wide attribute would be useful.
Switching attributes on and off will make your code more complicated. If one doesn't use scope-wide attributes much then he won't need to switch them off.
Jun 02 2015
parent "Wyatt" <wyatt.epp gmail.com> writes:
On Tuesday, 2 June 2015 at 15:13:44 UTC, ref2401 wrote:
 Switching attributes on and off will make your code more 
 complicated.
But not as complicated as working around the inability to do so already does. -Wyatt
Jun 02 2015
prev sibling parent reply "Dejan Lekic" <dejan.lekic gmail.com> writes:
On Tuesday, 2 June 2015 at 12:13:47 UTC, ref2401 wrote:
 On Tuesday, 2 June 2015 at 10:29:35 UTC, Daniel Kozak wrote:
 I am working on dip which will try to addressed negation of 
 attributes issue.
 http://wiki.dlang.org/DIP79
You propose to add extra difficulty to the language and the only reason is "If you need add few methods which are virtual or variables, you are forced to put them before final:. This is too limiting.". I think it's a bad idea.
I agree. On top of that, we have final { /* your final methods here */ } as a good alternative already. Finally, as far as I know, D will change the behaviour to final by default. What happened with that? Anything decided?
Jun 02 2015
next sibling parent "Namespace" <rswhite4 gmail.com> writes:
On Tuesday, 2 June 2015 at 15:18:55 UTC, Dejan Lekic wrote:
 On Tuesday, 2 June 2015 at 12:13:47 UTC, ref2401 wrote:
 On Tuesday, 2 June 2015 at 10:29:35 UTC, Daniel Kozak wrote:
 I am working on dip which will try to addressed negation of 
 attributes issue.
 http://wiki.dlang.org/DIP79
You propose to add extra difficulty to the language and the only reason is "If you need add few methods which are virtual or variables, you are forced to put them before final:. This is too limiting.". I think it's a bad idea.
I agree. On top of that, we have final { /* your final methods here */ } as a good alternative already. Finally, as far as I know, D will change the behaviour to final by default. What happened with that? Anything decided?
http://dgame.github.io/dneeds/#final-by-default
Jun 02 2015
prev sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 6/2/15 11:18 AM, Dejan Lekic wrote:
 On Tuesday, 2 June 2015 at 12:13:47 UTC, ref2401 wrote:
 On Tuesday, 2 June 2015 at 10:29:35 UTC, Daniel Kozak wrote:
 I am working on dip which will try to addressed negation of
 attributes issue.
 http://wiki.dlang.org/DIP79
You propose to add extra difficulty to the language and the only reason is "If you need add few methods which are virtual or variables, you are forced to put them before final:. This is too limiting.". I think it's a bad idea.
I agree. On top of that, we have final { /* your final methods here */ } as a good alternative already.
No, this is not good enough. Let's say we have 20 member functions of a struct/class. All of them are safe and nogc. All but a few are nothrow, all but a few (a different few) are pure. Some are const, some aren't. The most verbose way to do this is to put attributes on each function, blowing up all the signatures. The most effective way would be to do this: pure safe nothrow nogc { ... } And put attribute negations on the few odd functions that are different (including adding const, which I think appropriately belongs on each method that needs it). But your confusing mechanism is to pull out functions from their natural order outside the scope, and attribute them separately. But that screws up documentation, and it may separate overloads which naturally belong together. The best way is to label the oddballs, and we don't have a good way of doing that for most of the cases since the oddballs need less attributes.
 Finally, as far as I know, D will change the behaviour to final by
 default. What happened with that? Anything decided?
That is not happening. It was nixed by Andrei. -Steve
Jun 02 2015
prev sibling next sibling parent "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Tuesday, 2 June 2015 at 10:29:35 UTC, Daniel Kozak wrote:
 I am working on dip which will try to addressed negation of 
 attributes issue.
 http://wiki.dlang.org/DIP79
There are two subtly different things that "negation of attributes" can mean: a) switch off an attribute that has been enabled by `attr:` or `attr { }`, and b) switch on the opposite of an attribute. I guess this is about a)? Option b) would have further use cases, e.g. `cast(!const) ...`. Have you thought whether it should also be usable with UDAs? That would be more difficult than with normal attributes, because UDAs can be either values or types. Values would need to be comparable (opEquals). I would also strongly recommend not to allow CTFE expressions, should the `attr(...)` form be chosen.
Jun 02 2015
prev sibling next sibling parent "Kapps" <opantm2+spam gmail.com> writes:
This in theory reduce some kind of bugs, when one forget to mark 
method as virtual.
It doesn't reduce bugs, it introduces noticeable bugs and slightly lowers performance. All at the benefit of not having to write' virtual'. /pedantic As for the actual DIP, I don't like final(false). It's simply far too verbose, and a double negative (not not overridable), same for nogc(false). I slightly prefer !final (though it's again a double negative, but at least it's more consistent with bools and not function invocation), but even then it's not a nice solution. Only decent one I can think of though, short of adding virtual.
Jun 02 2015
prev sibling next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, 2 June 2015 at 10:29:35 UTC, Daniel Kozak wrote:
 I am working on dip which will try to addressed negation of 
 attributes issue.
 http://wiki.dlang.org/DIP79
You need to iron out what happens with attributes like safe/ trusted/ system or public/protected/package/private. Simply turning them on and off doesn't really work. Regardless, I think that attribute(boolean expression) is the clear winner, because it's for more flexible. Without the ability to provide a boolean expression, some code will be forced to use compile-time introspection to determine which attributes are enabled and then enable or disable them as appropriate in different static if branches. That sort of case is really only going to pop up in generic code, but once you start turning attributes on and off, I fully expect that it will come up, in which case, a syntax such as !final won't work very well. Also, Andrei has expressed interest in the attribute(boolean expression) syntax in the past, so that syntax has at least some support from him. - Jonathan M Davis
Jun 03 2015
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/3/15 2:19 PM, Jonathan M Davis wrote:
 Regardless, I think that attribute(boolean expression) is the clear
 winner, because it's for more flexible.
Yes please. -- Andrei
Jun 03 2015
parent reply Daniel =?UTF-8?B?S296w6Fr?= via Digitalmars-d writes:
On Wed, 03 Jun 2015 14:49:31 -0700
Andrei Alexandrescu via Digitalmars-d <digitalmars-d puremagic.com>
wrote:

 On 6/3/15 2:19 PM, Jonathan M Davis wrote:
 Regardless, I think that attribute(boolean expression) is the clear
 winner, because it's for more flexible.
Yes please. -- Andrei
Are we ok with code like this: final(someTemplate!orMaybeSomeAnother!SomeValue) finalOrVIrtualmethodWhoKnows() {} ? Maybe we can start with just attr(false) and attr(true), and add complete bool expresion evaluation in future?
Jun 04 2015
next sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Thu, 04 Jun 2015 09:13:47 +0200, Daniel Koz=C3=A1k via Digitalmars-d wro=
te:

 On Wed, 03 Jun 2015 14:49:31 -0700 Andrei Alexandrescu via Digitalmars-d
 <digitalmars-d puremagic.com>
 wrote:
=20
 On 6/3/15 2:19 PM, Jonathan M Davis wrote:
 Regardless, I think that attribute(boolean expression) is the clear
 winner, because it's for more flexible.
=20 Yes please. -- Andrei
=20 Are we ok with code like this: =20 final(someTemplate!orMaybeSomeAnother!SomeValue) finalOrVIrtualmethodWhoKnows() {} =20 ? =20 Maybe we can start with just attr(false) and attr(true), and add complete bool expresion evaluation in future?
:-(=
Jun 04 2015
prev sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, 4 June 2015 at 07:14:00 UTC, Daniel Kozák wrote:
 On Wed, 03 Jun 2015 14:49:31 -0700
 Andrei Alexandrescu via Digitalmars-d 
 <digitalmars-d puremagic.com>
 wrote:

 On 6/3/15 2:19 PM, Jonathan M Davis wrote:
 Regardless, I think that attribute(boolean expression) is 
 the clear
 winner, because it's for more flexible.
Yes please. -- Andrei
Are we ok with code like this: final(someTemplate!orMaybeSomeAnother!SomeValue) finalOrVIrtualmethodWhoKnows() {} ?
Yes, we're okay with that. That's precisely why we want it. And yes, it could be abused, but when dealing with generic code, but without it, things get a _lot_ uglier when you need to be doing introspection to determine what they should be (you'll end up with static if-else trees with almost duplicate declarations otherwise). A prime example would be when forwarding the attributes of a type that you're wrapping (like a range). If you need the attributes to match the ones being wrapped, then it's _way_ cleaner to be able to do something like auto front() const(isConst!(_wrapped.front)) { return _wrapped.front; } than if we only had const and !const. What we have now in this sort of situation is ugly enough, and this is a good opportunity to improve it. It would also be less error-prone than how we're stuck doing it now.
 Maybe we can start with just attr(false) and attr(true), and add
 complete bool expresion evaluation in future?
What would be the point of that? If all we're planning to do is have true and false, then you might as well just do attr and !attr. Accepting a boolean does nothing more for you unless it'll take arbitrary, compile-time expressions that resolve to a boolean. - Jonathan M Davis
Jun 04 2015
next sibling parent reply Daniel =?UTF-8?B?S296w6Fr?= via Digitalmars-d writes:
On Thu, 04 Jun 2015 08:31:30 +0000
Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 On Thursday, 4 June 2015 at 07:14:00 UTC, Daniel Kozák wrote:
 On Wed, 03 Jun 2015 14:49:31 -0700
 Andrei Alexandrescu via Digitalmars-d 
 <digitalmars-d puremagic.com>
 wrote:

 On 6/3/15 2:19 PM, Jonathan M Davis wrote:
 Regardless, I think that attribute(boolean expression) is 
 the clear
 winner, because it's for more flexible.
Yes please. -- Andrei
Are we ok with code like this: final(someTemplate!orMaybeSomeAnother!SomeValue) finalOrVIrtualmethodWhoKnows() {} ?
Yes, we're okay with that. That's precisely why we want it. And yes, it could be abused, but when dealing with generic code, but without it, things get a _lot_ uglier when you need to be doing introspection to determine what they should be (you'll end up with static if-else trees with almost duplicate declarations otherwise). A prime example would be when forwarding the attributes of a type that you're wrapping (like a range). If you need the attributes to match the ones being wrapped, then it's _way_ cleaner to be able to do something like auto front() const(isConst!(_wrapped.front)) { return _wrapped.front; } than if we only had const and !const. What we have now in this sort of situation is ugly enough, and this is a good opportunity to improve it. It would also be less error-prone than how we're stuck doing it now.
 Maybe we can start with just attr(false) and attr(true), and add
 complete bool expresion evaluation in future?
What would be the point of that? If all we're planning to do is have true and false, then you might as well just do attr and !attr. Accepting a boolean does nothing more for you unless it'll take arbitrary, compile-time expressions that resolve to a boolean. - Jonathan M Davis
If I will go with !attr, there will be no way to add compile-time expressions to it. But if we start with attr(true) or attr(false), it can be easily extended to support compile-time expressions in future.
Jun 04 2015
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, 4 June 2015 at 08:46:50 UTC, Daniel Kozák wrote:
 If I will go with !attr, there will be no way to add 
 compile-time
 expressions to it. But if we start with attr(true) or 
 attr(false), it
 can be easily extended to support compile-time expressions in 
 future.
I can see that. But I also see no point in designing it for possible extensibility later rather than just outright doing it now. At most, I can see implementing it with just attr(true) and attr(false) initially in order to get it in with the idea that we _will_ add full support for arbitrary, compile-time boolean expressions later, and not that we _might_ such support later. But my guess is that there really isn't much difference in the amount of work required to allow arbitrary compile-time boolean expressions, because we do that sort of thing in plenty of places already, so it's not like that would have to be done from scratch. I'm not a compiler dev though, and they'd have a better idea about that. Regardless, it's quite clear that we have cases in generic code where attr(boolean expression) will be useful, so we should just go for it. - Jonathan M Davis
Jun 04 2015
parent Daniel =?UTF-8?B?S296w6Fr?= via Digitalmars-d writes:
On Thu, 04 Jun 2015 16:19:23 +0000
Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 On Thursday, 4 June 2015 at 08:46:50 UTC, Daniel Kozák wrote:
 If I will go with !attr, there will be no way to add 
 compile-time
 expressions to it. But if we start with attr(true) or 
 attr(false), it
 can be easily extended to support compile-time expressions in 
 future.
I can see that. But I also see no point in designing it for possible extensibility later rather than just outright doing it now. At most, I can see implementing it with just attr(true) and attr(false) initially in order to get it in with the idea that we _will_ add full support for arbitrary, compile-time boolean expressions later, and not that we _might_ such support later. But my guess is that there really isn't much difference in the amount of work required to allow arbitrary compile-time boolean expressions, because we do that sort of thing in plenty of places already, so it's not like that would have to be done from scratch. I'm not a compiler dev though, and they'd have a better idea about that.
It is a much more amount of work. ATM final,pure, nogc are handled at parsing phase (There is a long value with one bit per one of each). If we want to add support for compile-time boolean we must use completely different approach. This will hurt compile time speed and add extra memory usage. There will be lots of places in code where this need to be solve. I allready start working on this https://github.com/Kozzi11/dmd/tree/rever_attr_2 It works somehow for final for now
 Regardless, it's quite clear that we have cases in generic code 
 where attr(boolean expression) will be useful, so we should just 
 go for it.
 
 - Jonathan M Davis
Jun 04 2015
prev sibling next sibling parent reply "Meta" <jared771 gmail.com> writes:
On Thursday, 4 June 2015 at 08:31:32 UTC, Jonathan M Davis wrote:
 Yes, we're okay with that. That's precisely why we want it. And 
 yes, it could be abused, but when dealing with generic code, 
 but without it, things get a _lot_ uglier when you need to be 
 doing introspection to determine what they should be (you'll 
 end up with static if-else trees with almost duplicate 
 declarations otherwise). A prime example would be when 
 forwarding the attributes of a type that you're wrapping (like 
 a range). If you need the attributes to match the ones being 
 wrapped, then it's _way_ cleaner to be able to do something like

 auto front() const(isConst!(_wrapped.front)) { return 
 _wrapped.front; }

 than if we only had const and !const. What we have now in this 
 sort of situation is ugly enough, and this is a good 
 opportunity to improve it. It would also be less error-prone 
 than how we're stuck doing it now.

 Maybe we can start with just attr(false) and attr(true), and 
 add
 complete bool expresion evaluation in future?
What would be the point of that? If all we're planning to do is have true and false, then you might as well just do attr and !attr. Accepting a boolean does nothing more for you unless it'll take arbitrary, compile-time expressions that resolve to a boolean. - Jonathan M Davis
It's still trivial to do this without allowing arbitrary expressions, since the expressions have to be CTFE-able. enum constIsEnabled = isConst!(_wrapped.front); auto front() const(constIsEnabled) { return _wrapped.front; }
Jun 04 2015
parent Kenji Hara via Digitalmars-d <digitalmars-d puremagic.com> writes:
2015-06-04 22:41 GMT+09:00 Meta via Digitalmars-d <
digitalmars-d puremagic.com>:

 It's still trivial to do this without allowing arbitrary expressions,
 since the expressions have to be CTFE-able.

 enum constIsEnabled = isConst!(_wrapped.front);
 auto front() const(constIsEnabled) { return _wrapped.front; }
In old days I thought a little more generic idea "compilable attribute". For example: // label style. // `str` is a CTFEable expression that returns // "public", "final", or other built-in attribute name. mixin(str): void f1() {} // block style mixin(str) { void f2() {} } // prefix style mixin(str) void f3() {} // postfix style void f4() mixin(str) {} Similar thing for UDAs // tuple contains CT entities that could be UDA. mixin(tuple): (Note that there's no consideration for feasibility). But I couldn't find the use case of them. Kenji Hara
Jun 04 2015
prev sibling parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 4 June 2015 at 10:46, Daniel Koz=C3=A1k via Digitalmars-d <
digitalmars-d puremagic.com> wrote:

 On Thu, 04 Jun 2015 08:31:30 +0000
 Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 On Thursday, 4 June 2015 at 07:14:00 UTC, Daniel Koz=C3=A1k wrote:
 On Wed, 03 Jun 2015 14:49:31 -0700
 Andrei Alexandrescu via Digitalmars-d
 <digitalmars-d puremagic.com>
 wrote:

 On 6/3/15 2:19 PM, Jonathan M Davis wrote:
 Regardless, I think that attribute(boolean expression) is
 the clear
 winner, because it's for more flexible.
Yes please. -- Andrei
Are we ok with code like this: final(someTemplate!orMaybeSomeAnother!SomeValue) finalOrVIrtualmethodWhoKnows() {} ?
Yes, we're okay with that. That's precisely why we want it. And yes, it could be abused, but when dealing with generic code, but without it, things get a _lot_ uglier when you need to be doing introspection to determine what they should be (you'll end up with static if-else trees with almost duplicate declarations otherwise). A prime example would be when forwarding the attributes of a type that you're wrapping (like a range). If you need the attributes to match the ones being wrapped, then it's _way_ cleaner to be able to do something like auto front() const(isConst!(_wrapped.front)) { return _wrapped.front; } than if we only had const and !const. What we have now in this sort of situation is ugly enough, and this is a good opportunity to improve it. It would also be less error-prone than how we're stuck doing it now.
 Maybe we can start with just attr(false) and attr(true), and add
 complete bool expresion evaluation in future?
What would be the point of that? If all we're planning to do is have true and false, then you might as well just do attr and !attr. Accepting a boolean does nothing more for you unless it'll take arbitrary, compile-time expressions that resolve to a boolean. - Jonathan M Davis
If I will go with !attr, there will be no way to add compile-time expressions to it. But if we start with attr(true) or attr(false), it can be easily extended to support compile-time expressions in future.
I don't see how having !attr will add value to D.
Jun 04 2015
prev sibling parent Daniel =?UTF-8?B?S296w6Fr?= via Digitalmars-d writes:
On Wed, 03 Jun 2015 21:19:19 +0000
Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 On Tuesday, 2 June 2015 at 10:29:35 UTC, Daniel Kozak wrote:
 I am working on dip which will try to addressed negation of 
 attributes issue.
 http://wiki.dlang.org/DIP79
You need to iron out what happens with attributes like safe/ trusted/ system or public/protected/package/private.
nothing, there is no need to revert them or do anything special
 Simply turning them on and off doesn't really work.
 
 Regardless, I think that attribute(boolean expression) is the 
 clear winner, because it's for more flexible. Without the ability 
 to provide a boolean expression, some code will be forced to use 
 compile-time introspection to determine which attributes are 
 enabled and then enable or disable them as appropriate in 
 different static if branches. That sort of case is really only 
 going to pop up in generic code, but once you start turning 
 attributes on and off, I fully expect that it will come up, in 
 which case, a syntax such as !final won't work very well.
Yes I know, but I still do not feel right about that.
Jun 04 2015
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-06-02 12:29, Daniel Kozak wrote:
 I am working on dip which will try to addressed negation of attributes
 issue.
 http://wiki.dlang.org/DIP79
What happens if you use this syntax for a UDA, compile time error? -- /Jacob Carlborg
Jun 03 2015
parent Daniel =?UTF-8?B?S296w6Fr?= via Digitalmars-d writes:
On Thu, 04 Jun 2015 08:45:34 +0200
Jacob Carlborg via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 On 2015-06-02 12:29, Daniel Kozak wrote:
 I am working on dip which will try to addressed negation of
 attributes issue.
 http://wiki.dlang.org/DIP79
What happens if you use this syntax for a UDA, compile time error?
Yes, but currently with not perfect error message :)
Jun 04 2015
prev sibling parent "iackhtak" <iackhtak gmail.com> writes:
On Tuesday, 2 June 2015 at 10:29:35 UTC, Daniel Kozak wrote:
 I am working on dip which will try to addressed negation of 
 attributes issue.
 http://wiki.dlang.org/DIP79
More general: attribute(Args...) safety(Safety.Pure): access(Access.Private): // assume private/protected/... is pseudo attributes access(Access.Package, "some.module"): override(Object): // override only Objects methods. IMO good idea to group method by owner override(false): cons: New keywords for same things. It hints things like __access. Ugly things:( New ways for same things Ugly
Jun 04 2015