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.
