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