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