Why is the 'in' operator nogc but the index operator is not?

void main() @nogc
{
    int[int] a;
    auto v = 0 in a; // OK
    auto w = a[0];   // Error: indexing an associative
                     // array in @nogc function main may
                     // cause GC allocation
}

On Monday, 16 February 2015 at 17:55:42 UTC, Jonathan Marler wrote:
> Why is the 'in' operator nogc but the index operator is not?
>
> void main() @nogc
> {
>     int[int] a;
>     auto v = 0 in a; // OK
>     auto w = a[0];   // Error: indexing an associative
>                      // array in @nogc function main may
>                      // cause GC allocation
> }

Might throw.

Am 16.02.2015 um 18:55 schrieb Jonathan Marler:
> Why is the 'in' operator nogc but the index operator is not?
>
> void main() @nogc
> {
>      int[int] a;
>      auto v = 0 in a; // OK
>      auto w = a[0];   // Error: indexing an associative
>                       // array in @nogc function main may
>                       // cause GC allocation
> }

Because the index operator throws a OutOfRange exception and throwing exceptions allocates, maybe?

On Monday, 16 February 2015 at 17:58:10 UTC, Benjamin Thaut wrote:
> Because the index operator throws a OutOfRange exception and throwing exceptions allocates, maybe?

Oh...I hadn't thought of that!  Thanks for the quick response.

On 2015-02-16 at 18:58, Benjamin Thaut wrote:
> Am 16.02.2015 um 18:55 schrieb Jonathan Marler:
>> Why is the 'in' operator nogc but the index operator is not?
>>
>> void main() @nogc
>> {
>>      int[int] a;
>>      auto v = 0 in a; // OK
>>      auto w = a[0];   // Error: indexing an associative
>>                       // array in @nogc function main may
>>                       // cause GC allocation
>> }
>
> Because the index operator throws a OutOfRange exception and throwing exceptions allocates, maybe?

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

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.

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.

On Tuesday, 17 February 2015 at 00:00:54 UTC, FG wrote:
> 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.

I'm not sure what you mean by Errors?  Are you talking about asserts?

On 2015-02-17 at 03:35, Jonathan Marler wrote:
> On Tuesday, 17 February 2015 at 00:00:54 UTC, FG wrote:
>> 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.
>
> I'm not sure what you mean by Errors?  Are you talking about asserts?

Asserts among them. I was talking about the two classes of Throwable: Error and Exception.

Errors: AssertError, FinalizeError, HiddenFuncError, InvalidMemoryOperationError, InvalidPointerError, NotImplementedError, OutOfMemoryError, ParallelForeachError, RangeError, SwitchError, SysError, ThreadError.

Exceptions: Base64Exception, CSVException, ConvException, CurlException, EncodingException, ErrnoException, FiberException,
FileException, FormatException, GetOptException, JSONException, OverflowException, ...