On 4 June 2015 at 10:46, Daniel Kozák via Digitalmars-d < [email protected]> wrote:
> > On Thu, 04 Jun 2015 08:31:30 +0000 > Jonathan M Davis via Digitalmars-d <[email protected]> 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 > > > <[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 > > 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.
