www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - trusted AKA most useless statement ever

reply Satoshi <satoshi rikarin.org> writes:
Simply, it should be replaced by:

void safeFunc()  safe {
     unsafe {
         auto vi = doUnsafeCall();
     }
}

 trusted functions are prohibited by d-idiom (so I don't know why 
are still in D).
So, when I need to create a simple window with OpenGL context I 
need to write about 10-15 calls to system functions. But 
D-idiom[1] for  trusted tells me to make  trusted functions as 
small as possible. OK, it makes sense.

but writing 20 times something like:
auto vi = (()  trusted => glXChooseXFBConfig(...))();

or:
auto vi = ()  trusted { return glXChooseXFBConfig(...); }();

is annoying and just forced me to mark whole class with 
 trusted...



[1] 
https://dlang.org/blog/2016/09/28/how-to-write-trusted-code-in-d/
Nov 25 2016
next sibling parent Stefan Koch <uplink.coder googlemail.com> writes:
On Friday, 25 November 2016 at 10:14:46 UTC, Satoshi wrote:

 Simply, it should be replaced by:

 void safeFunc()  safe {
     unsafe {
         auto vi = doUnsafeCall();
     }
 }

  trusted functions are prohibited by d-idiom (so I don't know 
 why are still in D).
 So, when I need to create a simple window with OpenGL context I 
 need to write about 10-15 calls to system functions. But 
 D-idiom[1] for  trusted tells me to make  trusted functions as 
 small as possible. OK, it makes sense.

 but writing 20 times something like:
 auto vi = (()  trusted => glXChooseXFBConfig(...))();

 or:
 auto vi = ()  trusted { return glXChooseXFBConfig(...); }();

 is annoying and just forced me to mark whole class with 
  trusted...



 [1] 
 https://dlang.org/blog/2016/09/28/how-to-write-trusted-code-in-d/


Encapsulate the function in a trusted wrapper if otfen.
Or simply not mark code that mucks with opengl as safe.
Because it is not.
Nov 25 2016
prev sibling next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Friday, 25 November 2016 at 10:14:46 UTC, Satoshi wrote:

 but writing 20 times something like:
 auto vi = (()  trusted => glXChooseXFBConfig(...))();


That's an anti-pattern and you should almost never actually do 
it. That is breaking the trusted thing, and is not what the blog 
means when it says keep the functions as small as possible.


 just forced me to mark whole class with  trusted...


If the class encapsulates unsafe activity into some kind of safe 
interface, that's what you are *supposed* to do.
Nov 25 2016
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/25/16 5:14 AM, Satoshi wrote:

 void safeFunc()  safe {
     unsafe {
         auto vi = doUnsafeCall();
     }
 }


How would this work for marking C functions assumed to be safe as 
trusted? -- Andrei
Nov 25 2016
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Friday, 25 November 2016 at 15:01:43 UTC, Andrei Alexandrescu 
wrote:

 How would this work for marking C functions assumed to be safe 
 as trusted? -- Andrei


You'd presumably just mark the prototypes as  safe too.
Nov 25 2016
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/25/16 10:30 AM, Adam D. Ruppe wrote:

 On Friday, 25 November 2016 at 15:01:43 UTC, Andrei Alexandrescu wrote:

 How would this work for marking C functions assumed to be safe as
 trusted? -- Andrei


 You'd presumably just mark the prototypes as  safe too.


Hmmm... ok, that would work by means of the convention " safe + no 
implementation really means trusted". Not too convenient I'd say. -- andrei
Nov 25 2016
next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Friday, 25 November 2016 at 16:03:27 UTC, Andrei Alexandrescu 
wrote:

 Hmmm... ok, that would work by means of the convention " safe + 
 no implementation really means trusted". Not too convenient I'd 
 say. -- andrei


It works today, though. The compiler will allow you to put  safe 
with no body and treat it exactly as if it were  trusted.

The only difference between  safe and  trusted in this sense is 
the mangled name.
Nov 25 2016
prev sibling parent Kagamin <spam here.lot> writes:
On Friday, 25 November 2016 at 16:03:27 UTC, Andrei Alexandrescu 
wrote:

 Hmmm... ok, that would work by means of the convention " safe + 
 no implementation really means trusted". Not too convenient I'd 
 say.


 trusted means " safe interface,  system implementation", so when 
you have only interface, it's legitimately  safe,  trusted would 
make no sense for it (barring mangling) since there's no 
implementation to apply  trusted to.
Nov 25 2016
prev sibling next sibling parent Guillaume Piolat <first.last gmail.com> writes:
On Friday, 25 November 2016 at 10:14:46 UTC, Satoshi wrote:

  trusted functions are prohibited by d-idiom (so I don't know 
 why are still in D).


Uh? No. I wonder where you've read this.
Nov 25 2016
prev sibling next sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 11/25/16 5:14 AM, Satoshi wrote:

 Simply, it should be replaced by:

 void safeFunc()  safe {
     unsafe {
         auto vi = doUnsafeCall();
     }
 }

  trusted functions are prohibited by d-idiom (so I don't know why are
 still in D).


No, they are not.  trusted escapes are for use when you can reasonably 
write most of the code with  safe (and get the benefits of the comipler 
checking safety for you). If you can't reasonably do that, you mark the 
whole function  trusted.


 So, when I need to create a simple window with OpenGL context I need to
 write about 10-15 calls to system functions. But D-idiom[1] for  trusted
 tells me to make  trusted functions as small as possible. OK, it makes
 sense.

 but writing 20 times something like:
 auto vi = (()  trusted => glXChooseXFBConfig(...))();

 or:
 auto vi = ()  trusted { return glXChooseXFBConfig(...); }();

 is annoying and just forced me to mark whole class with  trusted...


Marking the whole class as  trusted is fine. "As small as possible" 
might mean you have to mark the whole thing as  trusted, because no code 
can be reasonably marked  safe.

Without seeing your function, I can't say what the best marking should 
be, so maybe it does make sense to add all those trusted escapes. It's 
also possible to simply have an inner function marked  trusted, that 
does the same thing, but is less verbose.

The idea behind  trusted is to mark code as "this needs to be manually 
checked by hand". Any time you have  safe code, but your  trusted 
escapes mean that the  safe code also needs to be checked, you have 
mismarked it.

-Steve
Nov 25 2016
prev sibling parent Kagamin <spam here.lot> writes:
On Friday, 25 November 2016 at 10:14:46 UTC, Satoshi wrote:

 but writing 20 times something like:
 auto vi = (()  trusted => glXChooseXFBConfig(...))();

 or:
 auto vi = ()  trusted { return glXChooseXFBConfig(...); }();


Trusted blocks are used for safety inference in generic code, so 
that only code outside trusted blocks affects inferred safety of 
the generic function. Normally you should be fine by marking the 
trusted function with one  trusted attribute and be done with it, 
that's what it was designed for.


 is annoying and just forced me to mark whole class with 
  trusted...


And it also made code cleaner than with unsafe blocks sprinkled 
everywhere.
Nov 25 2016