Negation of attributes (DIP 79)

[Jonathan M Davis via Digitalmars-d]

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 at 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