Should we have an Unimplemented Attribute?

[Jonathan M Davis]

On Friday 04 February 2011 06:42:20 Andrej Mitrovic wrote:
> On 2/4/11, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
> > On Thursday 03 February 2011 20:51:01 Andrej Mitrovic wrote:
> >> Ah, I've just realized we already have the @disable attribute. This is
> >> practically what I was looking for.
> > 
> > That's more for doing stuff like disabling functions which the compiler
> > normally
> > takes care of if you don't - such as opAssign on arrays - but I suppose
> > that you
> > could use it for what you were looking for. Really though, I'd say that
> > correct
> > solution is usually to just comment out the code.
> > 
> > - Jonathan M Davis
> 
> I don't find that to be a good solution, unless I add another comment
> stating why the code was commented out. Otherwise, how am I to figure
> out why I commented some code out when I read it several weeks later?
> Is the code unfinished, faulty, a test case, ready to be removed, etc?
> Who knows..
> 
> You can take a look at Phobos for plenty of examples of commented out
> code, without any backup comments stating why they're commented out.
> Try figuring out why they're commented out if you haven't written that
> code yourself. You can only guess, or ask in the NG and hope someone
> remembers why.

Marking it as disabled doesn't help much. You still don't know _why_ it was 
disabled. Even if you know that that means that it's unfinished, you still 
wouldn't know what state it was in. If you did, commenting it out would have 
been plenty. So, regardless, you really should have an explanatory comment. I'm 
not about to claim that the commented out but unexplained code in Phobos is how 
such code should have been dealt with, but I really do think that unfinished code 
should be left commented until it _is_ finished. If an explanatory comment is 
necessary, then it should be added. Using @disable wouldn't make an explanatory 
comment any less necessary.

- Jonathan M Davis