DIP 1008 Preliminary Review Round 1

[Atila Neves via Digitalmars-d]

On Saturday, 27 May 2017 at 01:27:24 UTC, Walter Bright wrote:
> On 5/26/2017 11:58 AM, Atila Neves wrote:
>> On Friday, 26 May 2017 at 16:36:16 UTC, Walter Bright wrote:
>>> On 5/26/2017 4:50 AM, Steven Schveighoffer wrote:
>>>> But to answer your question, don't mark the exception scope 
>>>> in that case. The compiler should complain if you copy it 
>>>> outside the scope, no?
>>>
>>> I suspect if you proceed with that line of reasoning, you'll 
>>> wind up in the same place I did with DIP 1008.
>> 
>> Could you explain the line of reasoning that led you do 
>> dip1008? Thanks,
>
> Follow every construct that enables a reference to an Exception 
> to escape and figure out what you're going to do about it.

The idea would be that this only happens with `catch(scope T 
ex)`, so that the exception _can't_ escape. It can't be stored 
somewhere else, it can't be rethrown. It's going away so it's ok 
to call the destructor on it.

> After all, the call to free() must happen exactly once per 
> Exception that was allocated with malloc(), and one must also 
> deal with GC allocated Exceptions in the mix.

GC exceptions would just not do any work in the destructor.

> A typical omission is not considering with the rethrow case nor 
> the chaining case.

I omitted the chaining case in my example for brevity. A 
production-grade implementation would call the destructors of the 
exceptions in the chain. Sorry for not making that clear.

My idea is that every exception knows how to get rid of itself if 
by chance it's going away soon. And that if anyone wants to store 
a `@nogc` exception then that exception instance provides a 
`.dup` function.

I got to this idea by considering what it would like if we could 
catch smart pointers:

catch(RefCounted!Exception ex)

Then I made it simpler. TBH I'd rather be able to catch a smart 
pointer.

> Counter-proposals that don't do this are legion and I've 
> critiqued a lot of them for missing crucial cases. I'm getting 
> more reluctant to continue doing that, so I ask submitters of 
> them to be both much more complete, and if they are complete 
> solutions, provide a rationale as to why they are better than 
> DIP 1008 rather than being arguably equivalent.


I understand that, I'd have the same attitude towards other 
proposals if I were you. I know and confess I tend to be overly 
optimistic and fail to consider everything that can go wrong. The 
devil is indeed in the details.

Why do I think this scheme is better?

1. The programmer controls how allocation is done
2. Less of a special case (I admit it's a bit "special-casey")
3. Doesn't require another 2 druntime functions
4. Arguably easier to explain how it works

>
> Also keep in mind that DIP 1008 has an implementation sitting 
> in the PR queue, and it's fairly simple. Solutions that require 
> redesigning D or the compiler or both are not likely to get 
> much traction. The list of things I have to do next reminds me 
> of trying to run up the down escalator while it constantly 
> increases speed.

I could be completely wrong, but my intuition says that what I 
proposed wouldn't be too hard to implement either.

Atila