Fri, 27 Nov 2009 06:31:23 -0500, #ponce wrote: > I think that in the current design of safety, @trusted function and > normal functions are quite similar. An @unsafe proposal has been > rejected because of complexity. > > But here is a case that is left. > Sometimes in D1, I found that a function I tought trustworthy is in fact > completely buggy. I mark it "deprecated" to let the compiler found all > calls to this function. > > Here is a humble proposition for another safety policy which account for > that need. > > 1/ All "normal" functions are @trusted by default. They can call any > function. Remove the @trusted annotation. > > 2/ @safe functions call call @safe or normal functions. > > 2/ introduce a @crap annotation (or maybe @__@) for objects and > methods. The @crap annotation hilight bad code, bad design and provides > a handy metrics when reviewing code. Similar to the previously proposed > @unsafe annotation. > > 3/ remove the -safe switch and introduce -unsafe. In safe mode, any > function calling a @crap function becomes @crap. In unsafe mode, @crap > is not viral. > > 4/ @safe and @crap are of course mutually exclusive > > In short: > > - @safe can call: > - @safe functions > - normal functions > > - normal function can call: > - @safe functions > - normal functions > - @crap functions (but become @crap if in safe mode) > > - @crap functions can call anything. > > > I don't know if it's feasible. It supposes to trust the programmer more > than the current design, but the current design may lead to @trust abuse > imho... > > The main point is that functions are trusted by default. This proposal > makes @crap viral, to incent the programmer to eradicate it. It lowers > _a lot_ the guarantee you have when compiling -safe code, because it > implies the programmer to mark manually unsafe functions. This is a very > weak point. If one want to prove more safety, one may aswell put @crap: > on top of the module you are making safe and turn it to @safe > progressively. > > It accounts for two different needs : making guarantees about program > safety, and fixing a dangerous function without breaking anything. It's > also non-intrusive if the programmer is only interested by the second > goal. > > What do you think ?
I think the @crap annotation makes sense. Often I know some parts of code don't really have very good quality. It would help to tag them with some work-in-process sign. This is a much larger problem when several coders built a larger system. It's much easier to determine that anything that touches "crap" becomes "crap" than proving some sort of purity.