Negation of attributes (DIP 79)

[Iain Buclaw via Digitalmars-d]

On 4 June 2015 at 10:46, Daniel Kozák via Digitalmars-d <
digitalmars-d at puremagic.com> wrote:

>
> On Thu, 04 Jun 2015 08:31:30 +0000
> Jonathan M Davis via Digitalmars-d <digitalmars-d at 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 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
>
> 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.
>
>

I don't see how having !attr will add value to D.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20150604/a61bec5d/attachment.html>