On 4/4/2017 8:13 AM, deadalnix wrote:
> Then just do:
> auto ePtr = malloc(...);
> auto e = *(cast(Exception*) &ePtr);
> throw e;
>
> Problem solved, you did not used the GC.

Your proposal also seems to require that all allocations are done with the GC (otherwise, how can things be "transferred" to the GC?). How can various destroyers know which allocator was used with each object? (One could add a pointer to the allocator to all class objects.)

Does this preclude allocating on the stack, using malloc, using custom allocators, etc.?

> If the catch is owned, then the ownership of the Exception is transferred to the catch block. It is then either transferred back to the runtime in case of rethrow, or consumed/destroyed depending on what the catch block is doing with it.

What happens if the:

   catch (owned Exception e)

is faced with an Exception that is not owned? Does it not catch it at all? If so, doesn't that imply that for practical purposes all thrown Exceptions need to be owned? Or should there be overloading of catch blocks:

   try { ... }
   catch (owned Exception e) { ... }
   catch (scope Exception e) { ... }
   catch (Exception e) { ... }

It not look enticing.

On Wednesday, 5 April 2017 at 09:48:47 UTC, Walter Bright wrote:
>    try { ... }
>    catch (owned Exception e) { ... }
>    catch (scope Exception e) { ... }
>    catch (Exception e) { ... }
>
> It not look enticing.

You can do that, but that's 100% equivalent to:

>    try { ... }
>    catch (scope Exception e) { ... }

Unless you want to do something specific with the owned case ? You seems to be under the impression that this does anything specific for catch/throw when it doesn't.

Today, you can do

try { ... }
catch(immutable(Exception) e) { ... }

There is nothing different here.

On 4/4/17 12:26 AM, Nick B wrote:
> Can one assume that Walter is thinking about deadalnix's detailed proposal above, and that he will give a formal response, once he has given it serious thought, and discussed it with Andrei ?

As a matter of procedure no, a forum post will not be followed by a formal response. The DIP process ensures a formal response.

The post is far from what one would call a proposal, let alone a detailed one. It is a sketch of an idea that addresses a complex matter without minding a large number of details. That's totally fine; the whole discussion opener was also informal and lacking details. It's just that we can't work on someone else's vague idea.

I encourage anyone interested in pursuing this idea to work on a DIP.


Thanks,

Andrei

On Wednesday, 5 April 2017 at 12:14:38 UTC, Andrei Alexandrescu wrote:
> On 4/4/17 12:26 AM, Nick B wrote:
>> Can one assume that Walter is thinking about deadalnix's detailed proposal above, and that he will give a formal response, once he has given it serious thought, and discussed it with Andrei ?
>
> As a matter of procedure no, a forum post will not be followed by a formal response. The DIP process ensures a formal response.
>
> The post is far from what one would call a proposal, let alone a detailed one. It is a sketch of an idea that addresses a complex matter without minding a large number of details. That's totally fine; the whole discussion opener was also informal and lacking details. It's just that we can't work on someone else's vague idea.
>
> I encourage anyone interested in pursuing this idea to work on a DIP.
>
>
> Thanks,
>
> Andrei

In fairness, the DIP process is painfully slow (which I can suppose can be seen as either a good thing or a bad thing). DIP1003[0] has yet to be commented on, despite it being a simple and easily understandable change. Yes, during that time Dicebot quit as DIP manager, but when he quit this DIP was already over the deadline for comment by a couple weeks.

I went in not expecting a lot in terms of promptness and with the understanding that it was such a trivial and low-priority change that a prompt result was not really necessary (and thus I was willing to wait patiently), and yet I admit that in spite of all my goodwill I was frustrated by the lack of response after over 2 months.

My point is that I completely understand why someone would not want to bother going through the DIP process.

1. https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md

On Wednesday, 5 April 2017 at 17:08:55 UTC, Meta wrote:

> My point is that I completely understand why someone would not want to bother going through the DIP process.
>
> 1. https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md

FYI, Dicebot has been helping me get acquainted with the process and pointed out that 1003 is ready for a formal review. I'll be moving on it soon.

On Wednesday, 5 April 2017 at 12:14:38 UTC, Andrei Alexandrescu wrote:
> As a matter of procedure no, a forum post will not be followed by a formal response. The DIP process ensures a formal response.
>
> [...]
> I encourage anyone interested in pursuing this idea to work on a DIP.
>
>
> Thanks,
>
> Andrei

To be blunt I played the DIP game in the past, never again.

This is very time consuming and nobody gives a shit. You two just do whatever the heck you want at the end of the day. I'm just pointing I predicted the problem you are running into with your brilliant approach years before you realized it is a problem. You can decide to not listen, not really my problem.

I wrote fairly comprehensive specs of the idea in various places, including in the ML you created for this very topic. I just can't be writing specs again and again for them to be ignored, that's just not a productive use of my time, and at this point I'd even say it's not very respectful to ask people to waste more time.

I'm happy to work with you guy to come up with something, but I surely won't spend several days working a spec for nothing.

On 4/5/2017 5:07 AM, deadalnix wrote:
> You can do that, but that's 100% equivalent to:
>
>>    try { ... }
>>    catch (scope Exception e) { ... }
>
> Unless you want to do something specific with the owned case ? You seems to be
> under the impression that this does anything specific for catch/throw when it
> doesn't.

Your original proposal listed 3 different kinds of catch, now it seems different. It's clear to me that this is more of an idea than a proposal - a lot more work needs to go into it.

For example, adding an `owned` type constructor is a major, major language change. Issues of implicit conversion, overloading, covariance, partial ordering, type deduction, mangling, construction, postblit, TypeInfo, inout, etc., all have to be addressed and worked out. Then there's legacy compatibility, deprecation issues, interaction with other languages, interaction with multiple storage allocators, etc.

The C# paper is 5 years old, and it has not been adopted by C# for unknown reasons. C# is a much more constrained language than D is, making it more practical for C#. It not being adopted by C# suggests problems with it - perhaps it doesn't deliver the promised results enough to justify its cost?

Making this work for D involves a great deal of careful design work, and even more implementation work. It also includes some significant risk that it will prove unworkable.

I don't believe that a back-and-forth disjointed email chain here is going to resolve the major issues with it. Until a far more thorough design proposal is made, I'm going to bow out.

On 4/5/17 4:44 PM, deadalnix wrote:
> On Wednesday, 5 April 2017 at 12:14:38 UTC, Andrei Alexandrescu wrote:
>> As a matter of procedure no, a forum post will not be followed by a formal response. The DIP process ensures a formal response.
>>
>> [...]
>> I encourage anyone interested in pursuing this idea to work on a DIP.
>>
>>
>> Thanks,
>>
>> Andrei
> 
> To be blunt I played the DIP game in the past, never again.

Could you please point to the DIPs you have submitted? The only I know about is https://wiki.dlang.org/DIP27, which is of poor quality. You subsequently claimed you've invested significant work in it (https://forum.dlang.org/thread/hlckdmbpdlbjldcfwovj@forum.dlang.org) although the history of the DIP (https://wiki.dlang.org/?title=DIP27&action=history) reveals only a few small edits.

> This is very time consuming and nobody gives a shit.

Could you please watch the language. Thanks.

> You two just do whatever the heck you want at the end of the day. I'm just pointing I predicted the problem you are running into with your brilliant approach years before you realized it is a problem. You can decide to not listen, not really my problem.

It is easy to frame any issue at hand as a manifestation of a larger problem.

> I wrote fairly comprehensive specs of the idea in various places, including in the ML you created for this very topic. I just can't be writing specs again and again for them to be ignored, that's just not a productive use of my time, and at this point I'd even say it's not very respectful to ask people to waste more time.
> 
> I'm happy to work with you guy to come up with something, but I surely won't spend several days working a spec for nothing.

Thank you. If history is any indication, there is little to show after years of being around the community. The pattern seems to be a frustration that other people don't work on your ideas, which you can't convince yourself to spend time on. People tend to work on their own ideas, not others'. We don't have enough information to work on your vision, so absent that we work on our own.

To avoid being in a continuous state of frustration, you may want to take a risk and invest for real in your own ideas. They will have real impact if they are good.


Thanks,

Andrei

On Thursday, 6 April 2017 at 03:52:39 UTC, Andrei Alexandrescu wrote:
> Thank you. If history is any indication, there is little to show after years of being around the community. The pattern seems to be a frustration that other people don't work on your ideas, which you can't convince yourself to spend time on.

No the pattern is you guys propose something. You are pointed out that this thing won't work as well as expected and you'll run into problem X, Y and Z down the road.

You are then presented will alternatives that you ignore and chose to proceed anyway. When later on, you run into problem X, Y and Z, as predicted, you act like this is new to you, and ask for people to redo a bunch of work that you can ignore again.

You can point me as the lazy bum here, but there is a reasons why the lifetime ML died. You ignored all proposal that weren't your own and people stopped participating. I'm just the only one persistent enough to continue pointing it out.

On Wednesday, 5 April 2017 at 23:49:00 UTC, Walter Bright wrote:
> Your original proposal listed 3 different kinds of catch, now it seems different. It's clear to me that this is more of an idea than a proposal - a lot more work needs to go into it.
>

It is no different. These aren't special type of catch, no more than existing

try { ... }
catch (immutable(Exception) e) { ... }

is a special type of catch.

> For example, adding an `owned` type constructor is a major, major language change. Issues of implicit conversion, overloading, covariance, partial ordering, type deduction, mangling, construction, postblit, TypeInfo, inout, etc., all have to be addressed and worked out. Then there's legacy compatibility, deprecation issues, interaction with other languages, interaction with multiple storage allocators, etc.
>

Most of that was specified in the past and ignored.

> The C# paper is 5 years old, and it has not been adopted by C# for unknown reasons. C# is a much more constrained language than D is, making it more practical for C#. It not being adopted by C# suggests problems with it - perhaps it doesn't deliver the promised results enough to justify its cost?
>

In D, the cost/benefit ratio is higher because it solves problems with manual memory management that are irrelevant in C# and complete existing type system instead of creating something new.

However, the general idea is getting traction, as you can see from Herb's presentation at the CppCon posted in a previous post. His goal was to introduce GCed arenas in C++, the basic concept is the same.

> I don't believe that a back-and-forth disjointed email chain here is going to resolve the major issues with it. Until a far more thorough design proposal is made, I'm going to bow out.

It was specified to a fairly good extent in the lifetime ML (especialy the scope part, was specified in extreme details) and got ignored.

You got presented with most of what you are asking for now literally years ago and chose to ignore it. What about we start from there instead of asking me to redo all the work from scratch ?

I have people paying me to do useful work, and people who ask me to redo some work again and again for free and ignore it. Who do you think is getting most of my time ? I like D and all, but there are limits.