What would happen if the exception gets assigned to a global/TLS variable in a catch block. It would be copied to the GC heap?

On Sunday, 2 April 2017 at 05:16:23 UTC, Walter Bright wrote:
> then it is optimized to call 'allocate' instead.

Sounds like using compiler magic for changing the behavior of existing syntax rather than fixing the actual problem that std.allocators is trying to solve: unifying disparate allocation strategies/needs across libraries.

Do we really want to break a bunch of code and add another special case for this one specific problem, thereby making an already complicated language even more complicated?

Also, half of the nogc purists aren't going to be using druntime anyway.

On Monday, 3 April 2017 at 13:43:35 UTC, Jack Stouffer wrote:
> Also, half of the nogc purists aren't going to be using druntime anyway.

druntime is not GC.
C++ uses quite sizable runtime >1mb.

On Monday, 3 April 2017 at 14:20:48 UTC, Kagamin wrote:
> On Monday, 3 April 2017 at 13:43:35 UTC, Jack Stouffer wrote:
>> Also, half of the nogc purists aren't going to be using druntime anyway.
>
> druntime is not GC.
> C++ uses quite sizable runtime >1mb.

I don't know if you've been following some of the discussions here and on Learn, but there are a couple of people now link-hacking druntime completely out of their binaries in order to avoid implicit GC calls and implicit copying.

On Monday, 3 April 2017 at 14:27:47 UTC, Jack Stouffer wrote:
> I don't know if you've been following some of the discussions here and on Learn, but there are a couple of people now link-hacking druntime completely out of their binaries in order to avoid implicit GC calls and implicit copying.

I suppose they link-hack GC, not druntime. If they want to remove druntime, they can just not link with it in the first place: no druntime, nothing to remove. That's what I do, but never heard of implicit copying.

On Monday, 3 April 2017 at 14:36:43 UTC, Kagamin wrote:
> I suppose they link-hack GC, not druntime.

Nope, they get rid of everything, see https://theartofmachinery.com/2016/12/18/d_without_runtime.html

On 4/3/2017 3:58 AM, Jerry wrote:
> What would happen if the exception gets assigned to a global/TLS variable in a
> catch block. It would be copied to the GC heap?

You'd have to insert code to manually make a clone of the exception object. The compiler will complain if you try to leak the exception object.

On 4/3/2017 6:43 AM, Jack Stouffer wrote:
> Sounds like using compiler magic for changing the behavior of existing syntax
> rather than fixing the actual problem that std.allocators is trying to solve:
> unifying disparate allocation strategies/needs across libraries.

I don't see a point to having disparate allocation strategies for exception objects. In any case, the compiler will insert calls to specific functions to allocate/free exception objects. Those functions will be in druntime, but anyone can override them with their own implementation.


> Do we really want to break a bunch of code and add another special case for this
> one specific problem, thereby making an already complicated language even more
> complicated?

This particular solution will break very little existing code, and solves a fairly difficult problem.


> Also, half of the nogc purists aren't going to be using druntime anyway.

The idea of this proposal is to make a nogc program much more achievable. Currently, in order to not link with the GC, you can't use exceptions (or at least not in a memory safe manner). A solution without memory safety is not acceptable.

On Monday, April 03, 2017 14:00:53 Walter Bright via Digitalmars-d wrote:
> The idea of this proposal is to make a nogc program much more achievable. Currently, in order to not link with the GC, you can't use exceptions (or at least not in a memory safe manner). A solution without memory safety is not acceptable.

Yeah, the simple fact that you can't allocate exceptions in @nogc code is crippling to @nogc, and a lot of code that could otherwise be @nogc can't be because of exceptions - though the exception message poses a similar problem (especially if you'd normally construct it with format), and I don't know how you get around that other than not using anything more informative than string literals. Unless I missed something, this proposal seems to ignore that particular issue.

- Jonathan M Davis

On Monday, 3 April 2017 at 21:00:53 UTC, Walter Bright wrote:
> The idea of this proposal is to make a nogc program much more achievable. Currently, in order to not link with the GC, you can't use exceptions (or at least not in a memory safe manner). A solution without memory safety is not acceptable.

You could use an exception instance allocated in TLS (which is, in fact, what Weka does in large parts of the code). This should be perfectly memory safe, although there are of course implications for exception chaining. (By default, you'll still get an allocation for the associated TraceInfo, but you can disable that.)

Of course, this is not to say that a nicer/more general solution wouldn't be appreciated.

 — David