www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Temporary trusted scope

reply Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
What's the preferred way of creating a temporary  trusted scope 
without writing a separate  function?

Similar to Rust's

unsafe { /* unsafe stuff here */ }
Dec 18 2018
next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Tuesday, December 18, 2018 3:14:50 AM MST Per NordlŲw via Digitalmars-d-
learn wrote:
 What's the preferred way of creating a temporary  trusted scope
 without writing a separate  function?

 Similar to Rust's

 unsafe { /* unsafe stuff here */ }
Unfortunately, D does not currently have a way to do that. Only functions can be marked with trusted. However, the typical approach to this problem is to use a lambda, which is more or less syntactically the same except that it has some extra parens. e.g. () trusted { doUnsafe(); }(); or auto result = () trusted { getUnsafe:() }(); So, it's less than ideal, but it gets us close, and unless the code is long enough that maybe it should be in its own function, it's better than declaring a nested function, let alone declaring an entirely separate function at module scope. - Jonathan M Davis
Dec 18 2018
parent reply Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Tuesday, 18 December 2018 at 10:42:51 UTC, Jonathan M Davis 
wrote:
 Unfortunately, D does not currently have a way to do that. Only 
 functions can be marked with  trusted. However, the typical 
 approach to this problem is to use a lambda, which is more or 
 less syntactically the same except that it has some extra 
 parens. e.g.

 ()  trusted { doUnsafe(); }();
Is there a performance hit when using this?
Dec 18 2018
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 19/12/2018 1:34 AM, Per Nordlöw wrote:
 On Tuesday, 18 December 2018 at 10:42:51 UTC, Jonathan M Davis wrote:
 Unfortunately, D does not currently have a way to do that. Only 
 functions can be marked with  trusted. However, the typical approach 
 to this problem is to use a lambda, which is more or less 
 syntactically the same except that it has some extra parens. e.g.

 ()  trusted { doUnsafe(); }();
Is there a performance hit when using this?
Yes except for ldc with -O3. But it is a function not a delegate so it should be all nicely prefetched and ready to go. So I wouldn't worry about it too much.
Dec 18 2018
next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Tuesday, December 18, 2018 5:42:12 AM MST rikki cattermole via 
Digitalmars-d-learn wrote:
 On 19/12/2018 1:34 AM, Per NordlŲw wrote:
 On Tuesday, 18 December 2018 at 10:42:51 UTC, Jonathan M Davis wrote:
 Unfortunately, D does not currently have a way to do that. Only
 functions can be marked with  trusted. However, the typical approach
 to this problem is to use a lambda, which is more or less
 syntactically the same except that it has some extra parens. e.g.

 ()  trusted { doUnsafe(); }();
Is there a performance hit when using this?
Yes except for ldc with -O3. But it is a function not a delegate so it should be all nicely prefetched and ready to go. So I wouldn't worry about it too much.
Really? I would have thought that that would be a pretty obvious optimization (especially if inlining is enabled). I suppose that it doesn't entirely surprise me if dmd does a poor job of it, but I would have expected ldc to do better than that. I would think that such an improvement would be pretty low-hanging fruit for adding to dmd's optimizer though. If not, it sounds like further justification for adding a feature for this rather than having to use a lambda. Aside from that though, the lambda trick is simple enough that it wouldn't surprise me if Walter and Andrei's response to such a DIP would be to just use the lambda trick. - Jonathan M Davis
Dec 18 2018
next sibling parent Kagamin <spam here.lot> writes:
On Wednesday, 19 December 2018 at 06:11:48 UTC, Jonathan M Davis 
wrote:
 Really? I would have thought that that would be a pretty 
 obvious optimization (especially if inlining is enabled). I 
 suppose that it doesn't entirely surprise me if dmd does a poor 
 job of it, but I would have expected ldc to do better than 
 that. I would think that such an improvement would be pretty 
 low-hanging fruit for adding to dmd's optimizer though.
AFAIK, it was added.
Dec 19 2018
prev sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 19/12/2018 7:11 PM, Jonathan M Davis wrote:
 Really? I would have thought that that would be a pretty obvious
 optimization (especially if inlining is enabled).
Assembly doesn't lie.
Dec 19 2018
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Wednesday, December 19, 2018 1:19:42 AM MST rikki cattermole via 
Digitalmars-d-learn wrote:
 On 19/12/2018 7:11 PM, Jonathan M Davis wrote:
 Really? I would have thought that that would be a pretty obvious
 optimization (especially if inlining is enabled).
Assembly doesn't lie.
I'm not saying that you're wrong, just expressing surprise. I've never checked to see what code actually got generated. But I do think that it's something that the compiler should be smart enough to do even if it isn't currently that smart, and the fact that it isn't is most defintely not a good thing. - Jonathan M Davis
Dec 19 2018
parent rikki cattermole <rikki cattermole.co.nz> writes:
On 20/12/2018 5:02 AM, Jonathan M Davis wrote:
 On Wednesday, December 19, 2018 1:19:42 AM MST rikki cattermole via
 Digitalmars-d-learn wrote:
 On 19/12/2018 7:11 PM, Jonathan M Davis wrote:
 Really? I would have thought that that would be a pretty obvious
 optimization (especially if inlining is enabled).
Assembly doesn't lie.
I'm not saying that you're wrong, just expressing surprise. I've never checked to see what code actually got generated. But I do think that it's something that the compiler should be smart enough to do even if it isn't currently that smart, and the fact that it isn't is most defintely not a good thing. - Jonathan M Davis
I agree, this would be a very simple AST rewrite. Would be well worth doing since its a common-ish pattern.
Dec 19 2018
prev sibling parent Kagamin <spam here.lot> writes:
On Tuesday, 18 December 2018 at 12:42:12 UTC, rikki cattermole 
wrote:
 Yes except for ldc with -O3.
ldc with -O2 generates the same code.
Dec 19 2018
prev sibling parent reply Simen =?UTF-8?B?S2rDpnLDpXM=?= <simen.kjaras gmail.com> writes:
On Tuesday, 18 December 2018 at 10:14:50 UTC, Per Nordlöw wrote:
 What's the preferred way of creating a temporary  trusted scope 
 without writing a separate  function?
Jonathan's idea might also be encapsulated in a function, just like assumeUnique in Phobos: import std.stdio; template unsafe(alias fn) { trusted auto unsafe(T...)(T args) { return fn(args); } } system void fun(int n) { writeln("foo!"); } safe unittest { unsafe!({ fun(2); }); unsafe!fun(2); } -- Simen
Dec 18 2018
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 12/18/18 6:29 AM, Simen Kjærås wrote:
 On Tuesday, 18 December 2018 at 10:14:50 UTC, Per Nordlöw wrote:
 What's the preferred way of creating a temporary  trusted scope 
 without writing a separate  function?
Jonathan's idea might also be encapsulated in a function, just like assumeUnique in Phobos: import std.stdio; template unsafe(alias fn) {     trusted auto unsafe(T...)(T args) {         return fn(args);     } } system void fun(int n) {     writeln("foo!"); } safe unittest {     unsafe!({         fun(2);     });     unsafe!fun(2); }
Wow, I really like this. The only real problem is that one generally searches for trusted when looking for unsafe code, but unsafe is pretty obvious too. Also, args should be auto ref. Only thing better I can think of (for the second example) is to define a prototype with the correct information, only with trusted (and specify the mangle). But any decent compiler should get rid of any overhead there. -Steve
Dec 18 2018
next sibling parent Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Tuesday, 18 December 2018 at 13:52:29 UTC, Steven 
Schveighoffer wrote:
 template unsafe(alias fn) {
       trusted auto unsafe(T...)(T args) {
          return fn(args);
      }
 }
Very nice! What about proposing this for inclusion into `std.typecons` or `std.meta`?
Dec 18 2018
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Dec 18, 2018 at 08:52:29AM -0500, Steven Schveighoffer via
Digitalmars-d-learn wrote:
 On 12/18/18 6:29 AM, Simen KjśrŚs wrote:
 On Tuesday, 18 December 2018 at 10:14:50 UTC, Per NordlŲw wrote:
 What's the preferred way of creating a temporary  trusted scope
 without writing a separate† function?
Jonathan's idea might also be encapsulated in a function, just like assumeUnique in Phobos: import std.stdio; template unsafe(alias fn) { ††† trusted auto unsafe(T...)(T args) { ††††††† return fn(args); ††† } } system void fun(int n) { ††† writeln("foo!"); } safe unittest { ††† unsafe!({ ††††††† fun(2); ††† }); ††† unsafe!fun(2); }
Wow, I really like this. The only real problem is that one generally searches for trusted when looking for unsafe code, but unsafe is pretty obvious too. Also, args should be auto ref. Only thing better I can think of (for the second example) is to define a prototype with the correct information, only with trusted (and specify the mangle). But any decent compiler should get rid of any overhead there.
[...] I'm not so sure I like this. trusted bits of code really should have a safe API that cannot be called in a way that breaks safe. Being able to essentially "cast away" safe for arbitrary bits of code seems to me to be a rather scary, underhanded way of undermining safe. OTOH, if your function is very large and only isolated bits are non- safe, then a construct like this one could help, by making the code less noisy, and ensuring that the other parts of the code still remain safe. (Though IMO in such cases the function may be better refactored to encapsulate away the trusted bits in functions with safe APIs, and keep the safe code all in one place.) T -- MASM = Mana Ada Sistem, Man!
Dec 18 2018
parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 12/18/18 10:53 AM, H. S. Teoh wrote:
 On Tue, Dec 18, 2018 at 08:52:29AM -0500, Steven Schveighoffer via
Digitalmars-d-learn wrote:
 On 12/18/18 6:29 AM, Simen Kjærås wrote:
 On Tuesday, 18 December 2018 at 10:14:50 UTC, Per Nordlöw wrote:
 What's the preferred way of creating a temporary  trusted scope
 without writing a separate  function?
Jonathan's idea might also be encapsulated in a function, just like assumeUnique in Phobos: import std.stdio; template unsafe(alias fn) {     trusted auto unsafe(T...)(T args) {         return fn(args);     } } system void fun(int n) {     writeln("foo!"); } safe unittest {     unsafe!({         fun(2);     });     unsafe!fun(2); }
Wow, I really like this. The only real problem is that one generally searches for trusted when looking for unsafe code, but unsafe is pretty obvious too. Also, args should be auto ref. Only thing better I can think of (for the second example) is to define a prototype with the correct information, only with trusted (and specify the mangle). But any decent compiler should get rid of any overhead there.
[...] I'm not so sure I like this. trusted bits of code really should have a safe API that cannot be called in a way that breaks safe. Being able to essentially "cast away" safe for arbitrary bits of code seems to me to be a rather scary, underhanded way of undermining safe.
You may not be realizing what the point of this is. Essentially, you replace your inline trusted lambda with this call. It's just nicer syntax/usage without all the extra parentheses. Other than that, every usage of it would need as much scrutiny as a trusted lambda.
 OTOH, if your function is very large and only isolated bits are
 non- safe, then a construct like this one could help, by making the code
 less noisy, and ensuring that the other parts of the code still remain
  safe. (Though IMO in such cases the function may be better refactored
 to encapsulate away the  trusted bits in functions with safe APIs, and
 keep the  safe code all in one place.)
Yes, exactly. The point of trusted lambdas are so that only the parts you want to trust are actually trusted, the rest of the function is safe. It doesn't prevent you from having to locally verify that implementation leaks don't happen (for example, () trusted {free(ptr);}() can still leak dangling pointers out into the safe portion), but it allows you to focus where your code is trusted. For more details, see this: https://dlang.org/blog/2016/09/28/how-to-write-trusted-code-in-d/ -Steve
Dec 18 2018
prev sibling next sibling parent aliak <something something.com> writes:
On Tuesday, 18 December 2018 at 13:52:29 UTC, Steven 
Schveighoffer wrote:
 On 12/18/18 6:29 AM, Simen Kjærås wrote:
 On Tuesday, 18 December 2018 at 10:14:50 UTC, Per Nordlöw 
 wrote:
 What's the preferred way of creating a temporary  trusted 
 scope without writing a separate  function?
Jonathan's idea might also be encapsulated in a function, just like assumeUnique in Phobos: import std.stdio; template unsafe(alias fn) {     trusted auto unsafe(T...)(T args) {         return fn(args);     } } system void fun(int n) {     writeln("foo!"); } safe unittest {     unsafe!({         fun(2);     });     unsafe!fun(2); }
Wow, I really like this. The only real problem is that one generally searches for trusted when looking for unsafe code, but unsafe is pretty obvious too. Also, args should be auto ref. Only thing better I can think of (for the second example) is to define a prototype with the correct information, only with trusted (and specify the mangle). But any decent compiler should get rid of any overhead there. -Steve
I've been gathering assume related stuff like this in a lib under an "assume" template. You can generalize further with multiple attributes inside a non-eponymous thing and use them like: assume!fun.safe_(2); assume!fun.nogc_(2); I guess it's no very idiomatic D though, but I feel it reads better ... ok well maybe ūü§∑‚Äć‚ôāÔłŹ: https://aliak00.github.io/bolts/bolts/assume/assume.html Easier to be more specific with searches for "assumeSafe" instead of just "assume!" though. Cheers, - Ali
Dec 18 2018
prev sibling parent Simen =?UTF-8?B?S2rDpnLDpXM=?= <simen.kjaras gmail.com> writes:
On Tuesday, 18 December 2018 at 13:52:29 UTC, Steven 
Schveighoffer wrote:
 On 12/18/18 6:29 AM, Simen Kjærås wrote:
  safe unittest {
      unsafe!({
          fun(2);
      });
 
      unsafe!fun(2);
 }
Wow, I really like this. The only real problem is that one generally searches for trusted when looking for unsafe code, but unsafe is pretty obvious too. Also, args should be auto ref.
While trusted wouldn't work, it could be named 'trusted' instead of 'unsafe'. That's not gonna help those who search for ' trusted', but it's closer, at least. -- Simen
Dec 19 2018