<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 4 June 2015 at 10:46, Daniel Kozák via Digitalmars-d <span dir="ltr"><<a href="mailto:digitalmars-d@puremagic.com" target="_blank">digitalmars-d@puremagic.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
On Thu, 04 Jun 2015 08:31:30 +0000<br>
Jonathan M Davis via Digitalmars-d <<a href="mailto:digitalmars-d@puremagic.com">digitalmars-d@puremagic.com</a>> wrote:<br>
<br>
> On Thursday, 4 June 2015 at 07:14:00 UTC, Daniel Kozák wrote:<br>
> ><br>
> > On Wed, 03 Jun 2015 14:49:31 -0700<br>
> > Andrei Alexandrescu via Digitalmars-d<br>
> > <<a href="mailto:digitalmars-d@puremagic.com">digitalmars-d@puremagic.com</a>><br>
> > wrote:<br>
> ><br>
> >> On 6/3/15 2:19 PM, Jonathan M Davis wrote:<br>
> >> > Regardless, I think that attribute(boolean expression) is<br>
> >> > the clear<br>
> >> > winner, because it's for more flexible.<br>
> >><br>
> >> Yes please. -- Andrei<br>
> ><br>
> > Are we ok with code like this:<br>
> ><br>
> > final(someTemplate!orMaybeSomeAnother!SomeValue)<br>
> > finalOrVIrtualmethodWhoKnows() {}<br>
> ><br>
> > ?<br>
><br>
> Yes, we're okay with that. That's precisely why we want it. And<br>
> yes, it could be abused, but when dealing with generic code, but<br>
> without it, things get a _lot_ uglier when you need to be doing<br>
> introspection to determine what they should be (you'll end up<br>
> with static if-else trees with almost duplicate declarations<br>
> otherwise). A prime example would be when forwarding the<br>
> attributes of a type that you're wrapping (like a range). If you<br>
> need the attributes to match the ones being wrapped, then it's<br>
> _way_ cleaner to be able to do something like<br>
><br>
> auto front() const(isConst!(_wrapped.front)) { return<br>
> _wrapped.front; }<br>
><br>
> than if we only had const and !const. What we have now in this<br>
> sort of situation is ugly enough, and this is a good opportunity<br>
> to improve it. It would also be less error-prone than how we're<br>
> stuck doing it now.<br>
><br>
> > Maybe we can start with just attr(false) and attr(true), and add<br>
> > complete bool expresion evaluation in future?<br>
><br>
> What would be the point of that? If all we're planning to do is<br>
> have true and false, then you might as well just do attr and<br>
> !attr. Accepting a boolean does nothing more for you unless it'll<br>
> take arbitrary, compile-time expressions that resolve to a<br>
> boolean.<br>
><br>
> - Jonathan M Davis<br>
<br>
</div></div>If I will go with !attr, there will be no way to add compile-time<br>
expressions to it. But if we start with attr(true) or attr(false), it<br>
can be easily extended to support compile-time expressions in future.<br>
<br>
</blockquote></div><br><br></div><div class="gmail_extra">I don't see how having !attr will add value to D.<br><br><br></div></div>