Negation of attributes (DIP 79)

[Meta via Digitalmars-d]

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; }