Hi:
   In dlang core.thread.osthread has below code, the 654 line code i can understand why write () first, and {m_fn = fn;}()  do what?
```
   this( void function() fn, size_t sz = 0 ) @safe pure nothrow @nogc
   647     in
   648     {
   649         assert( fn );
   650     }
   651     do
   652     {
   653         this(sz);
   654         () @trusted { m_fn   = fn; }(); //What is the code mean?
   655         m_call = Call.FN;
   656         m_curr = &m_main;
   657     }
```

On Monday, 27 April 2020 at 13:29:08 UTC, lilijreey wrote:
> Hi:
>    In dlang core.thread.osthread has below code, the 654 line code i can understand why write () first, and {m_fn = fn;}()  do what?

The stdlib uses that pattern from time to time to indicate an unsafe block in an otherwise safe function.

Specifically it is a little trusted inline function being immediately called.

It is something that should be avoided whenever you can.

> The stdlib uses that pattern from time to time to indicate an unsafe block in an otherwise safe function.
>
> Specifically it is a little trusted inline function being immediately called.
>
> It is something that should be avoided whenever you can.

Thanks your help. where is unsafe in above code?

On Monday, 27 April 2020 at 13:36:25 UTC, Adam D. Ruppe wrote:
> On Monday, 27 April 2020 at 13:29:08 UTC, lilijreey wrote:
>> Hi:
>>    In dlang core.thread.osthread has below code, the 654 line code i can understand why write () first, and {m_fn = fn;}()  do what?
>
> The stdlib uses that pattern from time to time to indicate an unsafe block in an otherwise safe function.
>
> Specifically it is a little trusted inline function being immediately called.
>
> It is something that should be avoided whenever you can.

I'm probably not the first person to say this but. Isn't @trusted an odd label to give unsafe functions and open to abuse by unscrupulous programmers? It almost says "nothing to see, this here piece of code is a-ok". Shouldn't it be explicitly labelled as @unsafe?

27.04.2020 18:28, data pulverizer пишет:
> I'm probably not the first person to say this but. Isn't @trusted an odd label to give unsafe functions and open to abuse by unscrupulous programmers? It almost says "nothing to see, this here piece of code is a-ok". Shouldn't it be explicitly labelled as @unsafe?

It says "this piece of code is verified by its author manually so you (the compiler) can trust it is @safe"

On Monday, 27 April 2020 at 15:24:09 UTC, lilijreey wrote:
> Thanks your help. where is unsafe in above code?

It depends on the context but I assume it is because it is storing a reference to the function across thread boundaries, something normally banned, but since it is (I believe) a private member it is promising the compiler "trust me, I'm doing this implementation detail right". Hence the keyword "@trusted".

This is not the way that keyword was originally designed to be used, hence the janky syntax, but the stdlib authors use the pattern in a few places anyway.

On Monday, April 27, 2020 9:52:32 AM MDT drug via Digitalmars-d-learn wrote:
> 27.04.2020 18:28, data pulverizer пишет:
> > I'm probably not the first person to say this but. Isn't @trusted an odd label to give unsafe functions and open to abuse by unscrupulous programmers? It almost says "nothing to see, this here piece of code is a-ok". Shouldn't it be explicitly labelled as @unsafe?
>
> It says "this piece of code is verified by its author manually so you (the compiler) can trust it is @safe"

Exactly. @trusted isn't about marking something as not being memory safe. The compiler already treats anything as not being memory safe if it can't verify that it's memory safe. It's about the programmer telling the compiler that they've verified that it's memory safe even though the compiler couldn't. The code that neither the programmer nor the compiler has verified to be memory safe is @system. So, if we had the attribute @unsafe, it would have been instead of @system, not @trusted.

And ultimately, @trusted is not about telling anyone that there's "nothing to see." If anything, it's the opposite. @trusted code is the primary place that has to be examined when you have a memory bug in your code (or think that you have one). Barring bugs in the compiler, it should not be possible for @safe code to do anything that's memory unsafe, so when looking for memory safety bugs, it's the @trusted code that has to be examined to make sure that it actually is memory safe and that the programmer didn't use @trusted correctly.

- Jonathan M Davis

On Monday, 27 April 2020 at 13:36:25 UTC, Adam D. Ruppe wrote:
> On Monday, 27 April 2020 at 13:29:08 UTC, lilijreey wrote:
>> Hi:
>>    In dlang core.thread.osthread has below code, the 654 line code i can understand why write () first, and {m_fn = fn;}()  do what?
>
> The stdlib uses that pattern from time to time to indicate an unsafe block in an otherwise safe function.
>
> Specifically it is a little trusted inline function being immediately called.
>
> It is something that should be avoided whenever you can.

() { ... } ();

Is there a name of this kind of function in D? unnamed? anonymous?

On Tuesday, 28 April 2020 at 20:48:57 UTC, Net wrote:
> () { ... } ();
>
> Is there a name of this kind of function in D? unnamed? anonymous?

The spec uses "anonymous". Syntactically, `() { ... }` is a function literal.

There is a section called "Anonymous Functions and Anonymous Delegates" [1], but it's just a link to "Function Literals":

https://dlang.org/spec/expression.html#function_literals

To be clear, the second set of parentheses in `() { ... } ()` just calls the anonymous function. You could equivalently write it like this:

    alias f = () { ... };
    f();


[1] https://dlang.org/spec/function.html#anonymous

On 4/28/20 1:48 PM, Net wrote:
> () { ... } ();
>
> Is there a name of this kind of function in D? unnamed? anonymous?

Lambda or anonymous function.[1]

Note that the last () is not part of the definition but the execution of the function.

This idiom is used for initializing e.g. a const variable with non-trivial code as well (in C++ as well):

const a = {
    // ... some complex logic ...
    return result;
  }();

Ali

[1] I have a page that shows different syntaxes for lambda functions:

  http://ddili.org/ders/d.en/lambda.html#ix_lambda.=%3E