On Friday, 21 September 2018 at 11:48:50 UTC, Nemanja Boric wrote:
> On Friday, 21 September 2018 at 10:06:06 UTC, Nemanja Boric wrote:
>> On Friday, 21 September 2018 at 09:10:06 UTC, Jonathan M Davis wrote:
>>> [...]
>>
>> The @__future is fully (to a reasonable degree) implemented - and the `Throwable.message` was marked with this attribute to prevent breaking the user code when introducing this field, and it probably can just be removed from there at this point (since many releases have been released).
>>
>> [...]
>
> Interesting quote from Martin on that PR:
>
>> With regards to Throwable.message we agreed on making it one of the first users of an upcoming reference counted string. Details on the design of the reference counted string first to be discussed on dlang-study.

If in theory D had all the memory-safety features to make this work (think what languages like Rust have with linear/affine types [0] [1]) along with the necessary library implementations of smart pointers, RC-aware slicing, etc..., I would still prefer the sink-based approach in this situation, as it's much more elegant in my opinion.

[0]: http://wiki.c2.com/?LinearTypes
[1]: https://www.tweag.io/posts/2017-03-13-linear-types.html

On Thursday, 20 September 2018 at 12:48:13 UTC, Steven Schveighoffer wrote:
> On 9/20/18 6:48 AM, Atila Neves wrote:
>> On Wednesday, 19 September 2018 at 21:16:00 UTC, Steven Schveighoffer wrote:
>>> Given dip1008, we now can throw exceptions inside @nogc code! This is really cool, and helps make code that uses exceptions or errors @nogc. Except...
>>>
>>> The mechanism to report what actually went wrong for an exception is a string passed to the exception during *construction*. Given that you likely want to make such an exception inside a @nogc function, you are limited to passing a compile-time-generated string (either a literal or one generated via CTFE).
>> 
>> <snip>
>> 
>> I expressed my concern for DIP1008 and the `msg` field when it was first announced. I think the fix is easy and a one line change to dmd. I also expressed this on that thread but was apparently ignored. What's the fix? Have the compiler insert a call to the exception's destructor at the end of the `catch(scope Exception)` block. That's it. The `msg` field is just a slice, point it to RAII managed memory and you're good to go.
>> 
>> Give me deterministic destruction of exceptions caught by scope when using dip1008 and I'll give you @nogc exception throwing immediately. I've even already written the code!
>
> I thought it already did that?

Nope:

---------------
class MyException: Exception {
    static int numInstances;
    this(string msg) {
        super(msg);
        ++numInstances;
    }

    ~this() {
        --numInstances;
    }
}

void main() {
    assert(MyException.numInstances == 0);

    try
        throw new MyException("oops");
    catch(MyException _)
        assert(MyException.numInstances == 1);

    assert(MyException.numInstances == 0);
}
---------------

% dmd -dip1008 -run exception.d
core.exception.AssertError@exception.d(21): Assertion failure

> How is the exception destroyed when dip1008 is enabled?

Apparently, it isn't. Which renders dip1008 pretty much useless since we could already use static immutable exceptions before.

> But this means you still have to build msg when throwing the error/exception. It's not needed until you print it, and there's no reason anyway to make it allocate, even with RAII. For some reason D forces msg to be built, but it does't e.g. build the entire stack trace string before hand, or build the string that shows the exception class name or the file/line beforehand.


Allocating and building the string doesn't bother me - in all of my uses it's eventually going to get printed (which means the string needed to be built), and the exceptional path can be slow, I don't mind.

But, one could always store a tuple of members in an exception class instead and only build the string on demand.

I just think it's easier with an RAII string.

On Friday, 19 October 2018 at 23:34:01 UTC, Atila Neves wrote:
> On Thursday, 20 September 2018 at 12:48:13 UTC, Steven Schveighoffer wrote:
>> How is the exception destroyed when dip1008 is enabled?
>
> Apparently, it isn't. Which renders dip1008 pretty much useless since we could already use static immutable exceptions before.

Wow, that is useless! Is that an implementation bug or was that specified by the DIP?

On Friday, 19 October 2018 at 23:46:29 UTC, Nicholas Wilson wrote:
> On Friday, 19 October 2018 at 23:34:01 UTC, Atila Neves wrote:
>> On Thursday, 20 September 2018 at 12:48:13 UTC, Steven Schveighoffer wrote:
>>> How is the exception destroyed when dip1008 is enabled?
>>
>> Apparently, it isn't. Which renders dip1008 pretty much useless since we could already use static immutable exceptions before.
>
> Wow, that is useless! Is that an implementation bug or was that specified by the DIP?

I hope it's a bug - I opened an issue:

https://issues.dlang.org/show_bug.cgi?id=19317

On Thursday, 20 September 2018 at 17:14:12 UTC, Steven Schveighoffer wrote:
> On 9/20/18 12:24 PM, Adam D. Ruppe wrote:
>> On Thursday, 20 September 2018 at 15:52:03 UTC, Steven Schveighoffer wrote:
>>> I needed to know what the slice parameters that were failing were.
>> 
>> Aye. Note that RangeError is called by the compiler though, so you gotta patch dmd to make it pass the arguments to it for index. Ugh. I did a PR for this once but it got shot down because of an allegeded (without evidence btw) performance degradation. Ugh.
>
> Well, you can always override that. Just do the check yourself and throw the error you want ;)
>
> In my case, that's what I did anyway.
>
> I don't know how a performance problem can occur on an error being thrown anyway -- the process is about to end.
>
> -Steve

If `@nogc` could be relaxed for `new Error` exactly for that reason, pieces of Phobos could be turned `@nogc`...

But I admit that that change would be controversial...

- Paolo

On Saturday, 20 October 2018 at 13:48:32 UTC, Paolo Invernizzi wrote:

>
> If `@nogc` could be relaxed for `new Error` exactly for that reason, pieces of Phobos could be turned `@nogc`...
>
> But I admit that that change would be controversial...
>

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1008.md

On Saturday, 20 October 2018 at 14:56:37 UTC, Mike Parker wrote:
> On Saturday, 20 October 2018 at 13:48:32 UTC, Paolo Invernizzi wrote:
>
>>
>> If `@nogc` could be relaxed for `new Error` exactly for that reason, pieces of Phobos could be turned `@nogc`...
>>
>> But I admit that that change would be controversial...
>>
>
> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1008.md

Yep, you are right, of course...  8-/

/P

On Thursday, 20 September 2018 at 10:48:35 UTC, Atila Neves wrote:
> What's the fix? Have the compiler insert a call to the exception's destructor at the end of the `catch(scope Exception)` block.

If I understood you correctly then we have same idea. If exception is not handled or re thrown then scope "exits" trough scope(failure) in which case no deallocation should be performed and only if scope "exits" trough scope(success), meaning exception/s were handled, destructors need to be called.

To make exceptions nogc we need destructors that are aware of how scope was exited like:

~ this(exit) ( ) {}
~ this(success) ( ) {}
~ this(failure) ( ) {}

With this its easy to make all exceptions nogc