View mode: basic / threaded / horizontal-split · Log in · Help
November 27, 2009
Humble revamp of @trust, @safe and @unsafe
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 ?
November 27, 2009
Re: Humble revamp of @trust, @safe and @unsafe
#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.

No it hasn't been rejected. It's implemented in D2.037 (it's called 
@system now).
December 08, 2009
Re: Humble revamp of @trust, @safe and @unsafe
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.
Top | Discussion index | About this forum | D home