On Thursday, 15 December 2022 at 13:45:03 UTC, Adam D Ruppe wrote:

I was thinking to add a disabled default constructor for Throwable:

@disable immutable this();

But then every subclass of Throwable has to do the same. What if subclasses inherited a disabled constructor - that might solve the problem?

On Wednesday, 14 December 2022 at 01:47:29 UTC, Steven Schveighoffer wrote:

Is avoiding the GC inside exceptions a problem that needs to be solved? Maybe it is, but I don't think it's common to have a loop with millions of exceptions. Perhaps the issue is that there should be a version of @nogc that doesn't care about exceptions. With the current implementation of exceptions, the intersection of "avoiding GC" and "abusing exceptions" is almost certainly small.

On 12/15/22 6:04 PM, bachmeier wrote:

Why does the quantity of exceptions matter? The point of avoiding the GC is to avoid the collection, which can happen with a single allocation. If you want to avoid the GC for specific code paths, you don't want to say "OK, I guess I can't parse integers in here".

Note that it's also possible to assume the GC likely won't get triggered, because an exception is very unlikely. But having a mechanism to ask the compiler to help prove it, which can't be used, is pretty frustrating.

-Steve

On Thursday, 15 December 2022 at 23:29:55 UTC, Steven Schveighoffer wrote:

It matters if you expect the quantity to be zero. If you've thoroughly tested your code, and you're confident that the exception isn't relevant, it doesn't matter. It is quite rare that to!int would throw an exception in my code.

Those wanting that could continue to use the current @nogc. If they're fine with a one in a million chance of a collection, they don't need that kind of proof, and they could use @nogc right now with the 80% of Phobos you have cited.

On 12/15/22 7:27 PM, bachmeier wrote:

Totally agreed. But one to!int inside a big function makes it so it can't be @nogc. You might want the @nogc for other reasons. It just strikes me as limiting that converting string to int cancels the ability to use @nogc at all.

Maybe you misunderstood what I said. 20% of phobos is usable with @nogc (not tested, but that's my expectation). Fixing exceptions so they don't use the GC would be a single thing that flips that 20% to 80%.

-Steve

On Thursday, 15 December 2022 at 13:45:03 UTC, Adam D Ruppe wrote:

So I tried to mark this immutable data with VALGRIND_MAKE_MEM_NOACCESS and valgrind reports just a single write access to it from here: https://github.com/dlang/dmd/blob/v2.101.1/druntime/src/rt/deh.d#L46

Is it possible to construct the immutable exception data in a way that the cast(byte*) t !is typeid(t).initializer.ptr check would fail? What's the purpose of this check?

Another problem is illustrated by the example below:

T enforce(string msg, T)(T cond) {
    if (!cond) {
        static immutable e = new Exception(msg);
        throw e;
    }
    return cond;
}

void main() {
    try {
        enforce!"trigger an exception"(1 == 2);
    } catch (Exception e) {
        assert(0, "if we reach here, then it's probably a compiler bug");
    } catch (immutable Exception e) {
        // the proper place to handle it is here
        assert(e.msg == "trigger an exception");
    }
}

If it's an immutable exception, then the compiler should probably only catch it as immutable?

Right now it doesn't look like there are way too many problems preventing immutable exceptions from becoming usable.

On Friday, 16 December 2022 at 02:59:18 UTC, Walter Bright wrote:

It already is...

https://wiki.dlang.org/Memory_Management#Explicit_Class_Instance_Allocation

At best we can ask Beginner D tutorials/books to also refer to it

I think mike's blog post already does this though.

Yeah he does mention it: https://dlang.org/blog/2017/09/25/go-your-own-way-part-two-the-heap/

Even Ali's book mentions emplace, but not in the context of @nogc

Ali, if you're reading, perhaps this can be added?