Negation of attributes (DIP 79)

Daniel Kozák via Digitalmars-d digitalmars-d at puremagic.com
Thu Jun 4 01:46:34 PDT 2015


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.



More information about the Digitalmars-d mailing list