Andrei Alexandrescu píše v Pá 14. 03. 2014 v 08:17 -0700: > On 3/14/14, 4:37 AM, Daniel Murphy wrote: > > "Walter Bright" wrote in message news:lfu74a$8cr$1...@digitalmars.com... > > > >> > No, it doesn't, because it is not usable if C introduces any virtual > >> > methods. > >> > >> That's what the !final storage class is for. > > > > My mistake, I forgot you'd said you were in favor of this. Being able > > to 'escape' final certainly gets us most of the way there. > > > > !final is really rather hideous though. > > A few possibilities discussed around here: > > !final > ~final > final(false) > @disable final > > I've had an epiphany literally a few seconds ago that "final(false)" has > the advantage of being generalizable to "final(bool)" taking any > CTFE-able Boolean. > > On occasion I needed a computed qualifier (I think there's code in > Phobos like that) and the only way I could do it was through ugly code > duplication or odd mixin-generated code. Allowing computed > qualifiers/attributes would be a very elegant and general approach, and > plays beautifully into the strength of D and our current investment in > Boolean compile-time predicates. > > > Andrei >
First I think have something like @disable(final,nothrow) would be the best way, but than I think about it and realize that final(false) is much more better. Only advantege of @disable(all) or @disable(something, something_else) is we can disable more things more easily. But I almost never have needed this.