The D standard library is built on GC, is that a negative or positive?

[Adam D Ruppe]

On Thursday, 15 December 2022 at 13:30:57 UTC, Siarhei Siamashka 
wrote:
> Does it also GC allocate behind the scene?

Is the stack trace correct? If so, yes it does, but I think here 
since it is static immutable you'll just have an empty stack 
trace... but im not sure i shuold try running it but im lazy.

> Are there any other possible problems with it?

Yes, a lot.

1) `immutable` is ignored on exceptions. The implementation casts 
it away internally as it is thrown, so when it is caught, it is 
mutable again. If someone tried to actually modify it at this 
point, it is undefined behavior. (in this case i think the 
implementation would just retain the edits for another call to 
the same enforce msg, T arguments)

2) Similarly to #1, if someone were to catch then escape the 
reference to the exception (which is done by 
`core.thread.Thread.join` for example) they'd possibly find it 
changing out from under them.

Since it is marked `static immutable` this doesn't apply, but if 
it wasn't `immutable` at construction, it would be a thread-local 
variable which is, again, crash city if someone were to 
`Thread.join` since it'd be use-after-free then by definition 
(the thread local block is destroyed along with the thread, and 
thread.join terminates the thread). BTW this is also dip1008's 
core problem.

However, being a global instance, if two threads were to throw it 
simultaneously... this ties back to the immutable being casted 
away, but possible corruption to the data there too.


static exceptions work for simple cases but there's a number of 
pitfalls using them beyond the basics, especially when threads 
come into play.