Peter Alexander:

> * Does @nogc => nothrow? If I'm not mistaken, throw must through a GC-allocated Throwable.
>
> * If the above is true, does that mean exceptions cannot be used at all in @nogc code?

This should work:

void foo() @nogc nothrow {
    static const err = new Error("error");
    throw err;
}

Bye,
bearophile

On Wednesday, 16 April 2014 at 19:53:01 UTC, bearophile wrote:
> Peter Alexander:
>
>> * Does @nogc => nothrow? If I'm not mistaken, throw must through a GC-allocated Throwable.
>>
>> * If the above is true, does that mean exceptions cannot be used at all in @nogc code?
>
> This should work:
>
> void foo() @nogc nothrow {
>     static const err = new Error("error");
>     throw err;
> }
>
> Bye,
> bearophile

(I assume that nothrow isn't meant to be there?)

What if the exception needs information about the error?

You could do something like this:

void foo() @nogc
{
    static err = new Error();
    if (badthing)
    {
        err.setError("badthing happened");
        throw err;
    }
}

However, that raises a second question: since err is allocated when a new thread is created, does that mean @nogc functions cannot create threads in the presence of such static initialisation?

On Wednesday, 16 April 2014 at 19:44:19 UTC, Peter Alexander wrote:
> On Tuesday, 15 April 2014 at 17:01:38 UTC, Walter Bright wrote:
>> http://wiki.dlang.org/DIP60
>>
>> Start on implementation:
>>
>> https://github.com/D-Programming-Language/dmd/pull/3455
>
> Some initial thoughts:
>
> * Is it perhaps too early to introduce this? We don't have allocators yet, so it can be quite hard to avoid the GC in some situations.
>
> * Many Phobos functions use 'text' and 'format' in asserts. What should be done about those?

As a rule of thumb, format and text should *already* be avoided altogether in (non-static) asserts, as they can throw exceptions, preventing a function from being @nothrow. For example, sort:
https://github.com/D-Programming-Language/phobos/pull/2075/files#diff-ff74a46362b5953e8c88120e2490f839R9344

That said, the issue remains relevant for @nogc. Not only the exception itself, but also for the ".msg" field. How do we allocate it? Who cleans it up? Does the catcher have to do it? Can the catcher know he has to do it?

> * Does @nogc => nothrow? If I'm not mistaken, throw must through a GC-allocated Throwable.

Even then, what about asserts? Well, I guess it's OK if Errors leak, since you are supposed to terminate shortly afterwards.

> * If the above is true, does that mean exceptions cannot be used at all in @nogc code?
>
> * I worry about the number of attributes being added. Where do we draw the line? Are we going to add every attribute that someone finds a use for? @logicalconst @nonrecursive @nonreentrant @guaranteedtermination @neverreturns

I like the concept of having an "@everything" attribute. It "future proofs" code (in a way, if you are also fine with it potentially breaking). Also, it is often easier (I think) to not think in terms of "what guarantees does my function provide", but rather "what guarantees does my function *not* provide"? EG:

void myFun(int* p) @everyting impure;

My function is safe, nothrow, nogc etc... except pure.

BUT, I think this should be the subject of another thread. Let's focus on @nogc.

Peter Alexander:

> (I assume that nothrow isn't meant to be there?)

In D nothrow functions can throw errors.


> You could do something like this:
>
> void foo() @nogc
> {
>     static err = new Error();
>     if (badthing)
>     {
>         err.setError("badthing happened");
>         throw err;
>     }
> }

To be mutable err also needs to be __gshared.

Bye,
bearophile

Peter Alexander:

>        err.setError("badthing happened");

And that is usually written:

err.msg = "badthing happened";

Bye,
bearophile

On Wednesday, 16 April 2014 at 20:29:17 UTC, bearophile wrote:
> Peter Alexander:
>
>> (I assume that nothrow isn't meant to be there?)
>
> In D nothrow functions can throw errors.

Of course, ignore me :-)


>> You could do something like this:
>>
>> void foo() @nogc
>> {
>>    static err = new Error();
>>    if (badthing)
>>    {
>>        err.setError("badthing happened");
>>        throw err;
>>    }
>> }
>
> To be mutable err also needs to be __gshared.

But then it isn't thread safe. Two threads trying to set and throw the same Error is a recipe for disaster.

> Well, most of the new games (Unity3D) are done in C# nowadays and people live with it even though game development is one of the biggest C++ loving and GC hating crowd there is.

 Unity3D the engine is written primarily in C++, not C#.

The Unity editor and gameplay code is written in C# because that type of code is generally not performance sensitive.

On 4/16/2014 12:44 PM, Peter Alexander wrote:
> * Is it perhaps too early to introduce this? We don't have allocators yet, so it
> can be quite hard to avoid the GC in some situations.

Not that hard.

> * Many Phobos functions use 'text' and 'format' in asserts. What should be done
> about those?

Redo to use output ranges instead.


> * Does @nogc => nothrow?

No. They are orthogonal.


> If I'm not mistaken, throw must through a GC-allocated Throwable.
> * If the above is true, does that mean exceptions cannot be used at all in @nogc
> code?

They can use preallocated exceptions, or be templatized and infer the attributes. It is a problem, though.


> * I worry about the number of attributes being added. Where do we draw the line?
> Are we going to add every attribute that someone finds a use for? @logicalconst
> @nonrecursive @nonreentrant @guaranteedtermination @neverreturns

That's essentially true of every language feature.

On Wednesday, 16 April 2014 at 17:39:32 UTC, Walter Bright wrote:
> Not practical. malloc() is only one way of allocating memory - user defined custom allocators are commonplace.

Not sure why this is not practical. If the custom allocators are in D then you should be able to track all the way down to malloc. In sensitive code like NMIs you DO want to use custom allocators (allocating from a pool, ring buffer etc) or none at all.

However, I think it falls into the same group as tracking syscalls in a call chain. And I guess you would have to think about library/syscall tracers such as ltrace, dtrace/truss, strace, ktrace, SystemTap etc too…

Am 16.04.2014 22:49, schrieb froglegs:
>> Well, most of the new games (Unity3D) are done in C# nowadays and
>> people live with it even though game development is one of the biggest
>> C++ loving and GC hating crowd there is.
>
>   Unity3D the engine is written primarily in C++, not C#.
>
> The Unity editor and gameplay code is written in C# because that type of
> code is generally not performance sensitive.

I am really looking forward to .NET Native becoming widespread.

Then this type of comparisons (C# vs C++) will be quite different.

--
Paulo