@nogc with assoc array

[FG via Digitalmars-d-learn]

On 2015-02-16 at 22:12, Jonathan Marler wrote:
> On Monday, 16 February 2015 at 19:12:45 UTC, FG wrote:
>> Range violation is an Error, but never mind that. The real question is: given all the work related to @nogc, wouldn't it be better for such common Errors to be preallocated and only have file and line updated when they are thrown?
>>
>> @nogc already, because they simply cast typeid(OutOfMemoryError).init or typeid(InvalidMemoryOperationError).init:
>> extern (C) void onOutOfMemoryError(void* pretend_sideffect = null) @trusted pure nothrow @nogc
>> extern (C) void onInvalidMemoryOperationError(void* pretend_sideffect = null) @trusted pure nothrow @nogc
>>
>> Could be made @nogc with one object of each kind preallocated:
>> extern (C) void onAssertError( string file = __FILE__, size_t line = __LINE__ ) nothrow
>> extern (C) void onRangeError( string file = __FILE__, size_t line = __LINE__ ) @safe pure nothrow
>> extern (C) void onSwitchError( string file = __FILE__, size_t line = __LINE__ ) @safe pure nothrow
>
> This could be a good idea for some types of exceptions.  I believe OutOfMemory is already pre-allocated (it has to be since you can't allocate it once you are out of memory).  The problem with your suggestion is that if you allow the exception to be updated with the line number/filename(it isn't immutable), then you have to store it in TLS memory.  That may be an acceptable tradeoff, but you have to take that into consideration.  Also if you have a chain of exceptions you wouldn't be able to include the same exception more then once in the chain.
>
> The problem D has with exceptions and GC memory is complex and will have different optimal solutions in different cases.  In some cases, it would be better for D to support non-GC heap allocated exceptions.  Maybe these types of exceptions could be derived from another class so the user code will know that the memory needs to be freed.  There are also other ideas but my point is we should make a plan about what solutions we think would be good to implement and determine which ones we want to tackle first.

Yes, they would be in TLS. I know exceptions in general are a complex problem, therefore I limited the comment only to errors, because forbidding the use of `aa[key]` in @nogc seemed odd (although I do think that `aa.get(key, default)` and `key in aa` are superior to `aa[key]`). I have seen a few examples of Exception chaining, but not Error chaining, and since Error trumps Exception, whatever else was raised was of less importance to me, so I didn't give much thought to that.

And as for the extra non-GC exception class, maybe, I'm not sure, but it should nevertheless be a subclass of Exception to allow for a simple catch-all.