• #ponce (26/26) Nov 27 2009 I think that in the current design of safety, @trusted function and nor...
• Don (3/4) Nov 27 2009 No it hasn't been rejected. It's implemented in D2.037 (it's called
• retard (6/66) Dec 07 2009 I think the @crap annotation makes sense. Often I know some parts of cod...

#ponce <aliloko gmail.com> writes:

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 ?

Don <nospam nospam.com> writes:

#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).

retard <re tard.com.invalid> writes:

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.