• Walter Bright (15/15) Nov 10 2009 @unsafe was suggested (I think by Don) to provide symmetry with @safe
• bearophile (8/11) Nov 10 2009 If what you say is right, then what's the purpose/advantage of using:
• Walter Bright (6/18) Nov 10 2009 ...unsafe functions...
• Justin Johansson (6/27) Nov 10 2009 entia non sunt multiplicanda praeter necessitatem
• Bill Baxter (8/23) Nov 10 2009 I don't assume that a class is entirely private when I see private: at t...
• Don (14/33) Nov 11 2009 I'm thinking from a library developers viewpoint. Unsafe functions are
• Walter Bright (2/7) Nov 11 2009 That's something I hadn't thought of!
• Walter Bright (3/6) Nov 11 2009 That would be fairly viral. I'm concerned it would make it an impediment...
• Don (3/10) Nov 11 2009 Hopefully such functions would be really rare. It would be a strong
• Phil Deets (3/12) Nov 11 2009 I have a feeling people would throw on a @trusted wrapper just to save t...

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?

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

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

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

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

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

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!

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.

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.

"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'.

  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.

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