On Tuesday, 11 April 2017 at 00:46:51 UTC, Petar Kirov [ZombineDev] wrote:
> On Sunday, 9 April 2017 at 03:26:14 UTC, Walter Bright wrote:
>> My previous version did not survive implementation. Here's the revised version. I have submitted it as a DIP, and there's a trial implementation up:
>>
>> [...]
>
> Instead of adding new runtime helper functions like _d_newThrowable and _d_delThrowable, can we leverage the existing (though deprecated) support for class (de)allocators and essentially divide the _d_delThrowable implementation between the destructor and the deallocator member function? This will go hand in hand with the work that Lucia has been doing on making the runtime more generic and reducing the number of special cases in the compiler [1] [2] [3]. Obviously you have done the work already, but in theory at least, with my proposal users should be able to override the memory allocation method in derived exception classes, without any changes to druntime.
>
> [1]: https://github.com/dlang/druntime/pull/1781
> [2]: https://github.com/dlang/druntime/pull/1792
> [3]: http://dconf.org/2017/talks/cojocaru.html

Apart from that the proposal seems fine to me. I would much prefer a more general/principled solution to the problem like the one deadalnix proposes, but that shouldn't stop us from experimenting with an ad hoc approach in the short-term, while a more solid solution is developed.

On 4/10/2017 5:11 PM, Adam D. Ruppe wrote:
> `new` itself isn't really changing since it was already allowed to do this in
> cases the compiler can prove its lifetime.

Right. It isn't required to actually allocate it on the GC, just that it behaves as if it did.

The real change in semantics is the implicit addition of 'scope' on the catch object declaration.

On Tuesday, 11 April 2017 at 00:11:01 UTC, Adam D. Ruppe wrote:
> On Monday, 10 April 2017 at 23:16:48 UTC, Meta wrote:
>> My knee jerk reaction is that it's a very bad thing that "new" means the same thing everywhere in the language (allocate and initialize some GC-managed memory), except for this one case.
>
> Actually, in addition to user defined overloads (which are deprecated, granted), `new` also can mean stack allocation already! See the `scope` storage class and scope classes.

I don't agree as you have to add `scope` for the class to be allocated on the stack.

> The language is free to optimize `new` as it sees fit. (IMO, that's the only real justification for it even being a built in language feature instead of an ordinary library function.) The real changes in this proposal are:

Yes, but it must be done in such a way that a user never knows the difference. I have my doubts about whether replacing all heap allocations in `throw new` expressions will be as transparent. Actually it's already not as there are restrictions on catch blocks that catch refcounted Exceptions.

On 4/10/2017 5:46 PM, Petar Kirov [ZombineDev] wrote:
> Instead of adding new runtime helper functions like _d_newThrowable and
> _d_delThrowable, can we leverage the existing (though deprecated) support for
> class (de)allocators and essentially divide the _d_delThrowable implementation
> between the destructor and the deallocator member function? This will go hand in
> hand with the work that Lucia has been doing on making the runtime more generic
> and reducing the number of special cases in the compiler [1] [2] [3]. Obviously
> you have done the work already, but in theory at least, with my proposal users
> should be able to override the memory allocation method in derived exception
> classes, without any changes to druntime.

I considered that, but discarded it because then all Throwables would be allocated that way, in a completely uncontrolled manner.

On 4/10/2017 6:41 AM, Andrew Godfrey wrote:
> I'm just curious: The proposal doesn't mention interop with C++ exception
> handlers. I don't know the status of that so I'll just ask: Can C++ code catch D
> exceptions?

No. D can catch C++ exceptions.

On Tuesday, April 11, 2017 01:05:10 Walter Bright via Digitalmars-d wrote:
> On 4/10/2017 6:41 AM, Andrew Godfrey wrote:
> > I'm just curious: The proposal doesn't mention interop with C++
> > exception
> > handlers. I don't know the status of that so I'll just ask: Can C++ code
> > catch D exceptions?
>
> No. D can catch C++ exceptions.

What does this look like? I recall you discussing planning adding the ability for D to catch C++ exceptions, but I was unaware that it had been implemented yet. Certainly, I couldn't find it in the documentation when I went looking a month or two back. But I wouldn't think that catching Exception would work if it's a C++ exception - even if it's a std::exception, since std::exception doesn't have the same functions as Exception or Throwable. So, how would you catch a C++ exception in D?

- Jonathan M Davis

This idea could be generalized:

-DRuntime would add an interface "ReferenceCountable".
-Throwable would implement it.
-When a new expression of ReferenceCountable type is used to assign to a scope variable or argument, it's guaranteed to be @nogc.
-Non-scoped objects, ReferenceCountable or no, are assumed to not be reference counted.

I wonder it this is what Jack Stouffer was thinking?

On Mon, 10 Apr 2017 16:43:40 -0700, Walter Bright wrote:

> On 4/10/2017 2:44 PM, Jonathan Marler wrote:
>> Another way to think of it is that this proposal makes "throw new" into a special operator that is different than composing the "throw" and "new" operations independently. Once you realize this it's easy to understand and explain to others as well, i.e.
>>
>> "throw"     operator (throw a Throwable object)
>> "new"       operator (create a GC object)
>> "throw new" operator (create and throw a reference-counted Throwable
>> object)
> 
> That's right. Thanks for helping out, your explanations are better than mine!
> 
> (Once I realized this myself, the implementation got a lot simpler.)

I have no problem with this specific change, but this method of solving problems is going to turn D into a horrible language with all kinds of weird edge cases. I left Python for D mostly because the language was becoming one hack built on top of another; it would be nice if D could avoid that path. The occasional kludge may be necessary, but it shouldn't be normal or the first thought.

--Ryan

On 2017-04-10 22:10, Jonathan Marler wrote:

> The compiler makes it refcounted if and only if you are "throwing" and
> "newing" in the same statment, i.e.
>
>     throw new E(); // refcounted

Aha, now I understand. I don't think that was very clear from the beginning.

-- 
/Jacob Carlborg

On 2017-04-11 04:11, Meta wrote:

> I don't agree as you have to add `scope` for the class to be allocated
> on the stack.

It's enough to add "scope" when declaring the variable:

scope foo = new Object;

-- 
/Jacob Carlborg