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
<[email protected]>
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
