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