On Thursday, 4 June 2015 at 08:46:50 UTC, Daniel Kozák wrote:
> 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 can see that. But I also see no point in designing it for possible extensibility later rather than just outright doing it now. At most, I can see implementing it with just attr(true) and attr(false) initially in order to get it in with the idea that we _will_ add full support for arbitrary, compile-time boolean expressions later, and not that we _might_ such support later. But my guess is that there really isn't much difference in the amount of work required to allow arbitrary compile-time boolean expressions, because we do that sort of thing in plenty of places already, so it's not like that would have to be done from scratch. I'm not a compiler dev though, and they'd have a better idea about that.

Regardless, it's quite clear that we have cases in generic code where attr(boolean expression) will be useful, so we should just go for it.

- Jonathan M Davis

On Thu, 04 Jun 2015 16:19:23 +0000
Jonathan M Davis via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On Thursday, 4 June 2015 at 08:46:50 UTC, Daniel Kozák wrote:
> > 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 can see that. But I also see no point in designing it for possible extensibility later rather than just outright doing it now. At most, I can see implementing it with just attr(true) and attr(false) initially in order to get it in with the idea that we _will_ add full support for arbitrary, compile-time boolean expressions later, and not that we _might_ such support later. But my guess is that there really isn't much difference in the amount of work required to allow arbitrary compile-time boolean expressions, because we do that sort of thing in plenty of places already, so it's not like that would have to be done from scratch. I'm not a compiler dev though, and they'd have a better idea about that.

It is a much more amount of work. ATM final,pure,@nogc are handled at
parsing phase (There is a long value with one bit per one of each). If
we want to add support for compile-time boolean we must use completely
different approach. This will hurt compile time speed and add extra
memory usage. There will be lots of places in code where this need to
be solve. I allready start working on this
https://github.com/Kozzi11/dmd/tree/rever_attr_2

It works somehow for final for now

> Regardless, it's quite clear that we have cases in generic code where attr(boolean expression) will be useful, so we should just go for it.
> 
> - Jonathan M Davis