www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Do we really need unsafe?

reply Walter Bright <newshound1 digitalmars.com> writes:
 unsafe was suggested (I think by Don) to provide symmetry with  safe 
and  trusted. This is a good point, but I'm starting to think that 
 unsafe is not a good idea.

For example, one could make an entire module safe with:

-------------------
module foo;
 safe:
[...]
-------------------

And an observer could conclude that foo only contains safe and trusted 
code. But if  unsafe could override, he has to delve into it looking for 
 unsafe as well.

Furthermore, why would a safe module wish to expose unsafe functions? 
Shouldn't the programmer instead be obliged to produce trusted functions 
in it?
Nov 10 2009
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:

 Furthermore, why would a safe module wish to expose unsafe functions? 
 Shouldn't the programmer instead be obliged to produce trusted functions 
 in it?

If what you say is right, then what's the purpose/advantage of using: module foo; safe: Instead of this? module(safe) foo; Bye, bearophile
Nov 10 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
bearophile wrote:
 Walter Bright:
 
 Furthermore, why would a safe module wish to expose unsafe functions? 
 Shouldn't the programmer instead be obliged to produce trusted functions 
 in it?

If what you say is right, then what's the purpose/advantage of using: module foo; safe: Instead of this? module(safe) foo;

...unsafe functions... safe: ...safe functions... trusted: ...trusted functions...
Nov 10 2009
parent Justin Johansson <no spam.com> writes:
Walter Bright Wrote:

 bearophile wrote:
 Walter Bright:
 
 Furthermore, why would a safe module wish to expose unsafe functions? 
 Shouldn't the programmer instead be obliged to produce trusted functions 
 in it?

If what you say is right, then what's the purpose/advantage of using: module foo; safe: Instead of this? module(safe) foo;

...unsafe functions... safe: ...safe functions... trusted: ...trusted functions...

entia non sunt multiplicanda praeter necessitatem I would err on Walter's side; the fewer the number of options/keywords to achieve the required functionality the better and no fewer. Justin
Nov 10 2009
prev sibling next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Tue, Nov 10, 2009 at 3:56 PM, Walter Bright
<newshound1 digitalmars.com> wrote:
  unsafe was suggested (I think by Don) to provide symmetry with  safe and
  trusted. This is a good point, but I'm starting to think that  unsafe is
 not a good idea.

 For example, one could make an entire module safe with:

 -------------------
 module foo;
  safe:
 [...]
 -------------------

 And an observer could conclude that foo only contains safe and trusted code.
 But if  unsafe could override, he has to delve into it looking for  unsafe
 as well.

I don't assume that a class is entirely private when I see private: at the top. Incremental search and grep are not difficult to use if you're trying to find out if a module contains anything unsafe.
 Furthermore, why would a safe module wish to expose unsafe functions?
 Shouldn't the programmer instead be obliged to produce trusted functions in
 it?

Private implementation might be using unsafe functions as part of the implementation of trusted functions. --bb
Nov 10 2009
prev sibling parent reply Don <nospam nospam.com> writes:
Walter Bright wrote:
  unsafe was suggested (I think by Don) to provide symmetry with  safe 
 and  trusted. This is a good point, but I'm starting to think that 
  unsafe is not a good idea.
 
 For example, one could make an entire module safe with:
 
 -------------------
 module foo;
  safe:
 [...]
 -------------------
 
 And an observer could conclude that foo only contains safe and trusted 
 code. But if  unsafe could override, he has to delve into it looking for 
  unsafe as well.
 
 Furthermore, why would a safe module wish to expose unsafe functions? 
 Shouldn't the programmer instead be obliged to produce trusted functions 
 in it?

I'm thinking from a library developers viewpoint. Unsafe functions are required to allow users to write their own trusted functions. It's possible to make these functions private, but that's at the expense of functionality. If we don't have unsafe, then an unlabelled function means the function is either "not checked for safety" _or_ "known to be unsafe". Those are two radically different things. Even if not using SafeD, marking functions as unsafe is valuable documentation. Actually, I'd hope for a way of checking that unsafe functions are called only from trusted functions, and NOT from unmarked ones -- that's the way I'd proceed in moving a codebase over to 'safe'. Based on the idea that the most common cause of safety violation is via passing incorrect parameters. (contracts are based on the same idea).
Nov 11 2009
next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Don wrote:
 Actually, I'd hope for a way of checking that  unsafe functions are 
 called only from  trusted functions, and NOT from unmarked ones -- 
 that's the way I'd proceed in moving a codebase over to 'safe'.
 Based on the idea that the most common cause of safety violation is via 
 passing incorrect parameters. (contracts are based on the same idea).

That's something I hadn't thought of!
Nov 11 2009
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Don wrote:
 Actually, I'd hope for a way of checking that  unsafe functions are 
 called only from  trusted functions, and NOT from unmarked ones -- 
 that's the way I'd proceed in moving a codebase over to 'safe'.

That would be fairly viral. I'm concerned it would make it an impediment to use.
Nov 11 2009
parent Don <nospam nospam.com> writes:
Walter Bright wrote:
 Don wrote:
 Actually, I'd hope for a way of checking that  unsafe functions are 
 called only from  trusted functions, and NOT from unmarked ones -- 
 that's the way I'd proceed in moving a codebase over to 'safe'.

That would be fairly viral. I'm concerned it would make it an impediment to use.

Hopefully such functions would be really rare. It would be a strong encouragement to wrap them in an trusted wrapper.
Nov 11 2009
prev sibling parent "Phil Deets" <pjdeets2 gmail.com> writes:
On Wed, 11 Nov 2009 06:04:16 -0500, Don <nospam nospam.com> wrote:

 Walter Bright wrote:
 Don wrote:
 Actually, I'd hope for a way of checking that  unsafe functions are  
 called only from  trusted functions, and NOT from unmarked ones --  
 that's the way I'd proceed in moving a codebase over to 'safe'.

impediment to use.

Hopefully such functions would be really rare. It would be a strong encouragement to wrap them in an trusted wrapper.

I have a feeling people would throw on a trusted wrapper just to save the work on propagating unsafe attributes all through their code.
Nov 11 2009