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.