www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Exceptions in nogc code

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Walter and I discussed the following promising setup:

Use "throw new scope Exception" from  nogc code. That will cause the 
exception to be allocated in a special stack-like region.

If the catching code uses "catch (scope Exception obj)", then a 
reference to the exception thus created will be passed to catch. At the 
end of the catch block there's no outstanding reference to "obj" so it 
will be freed. All  nogc code must use this form of catch.

If the catching code uses "catch (Exception obj)", the exception is 
cloned on the gc heap and then freed.

Finally, if an exception is thrown with "throw new Exception" it can be 
caught with "catch (scope Exception obj)" by copying the exception from 
the heap into the special region, and then freeing the exception on the 
heap.

Such a scheme preserves backward compatibility and leverages the work 
done on "scope".


Andrei
Apr 01 2017
next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
On 01/04/2017 2:34 PM, Andrei Alexandrescu wrote:

 Walter and I discussed the following promising setup:

 Use "throw new scope Exception" from  nogc code. That will cause the
 exception to be allocated in a special stack-like region.

 If the catching code uses "catch (scope Exception obj)", then a
 reference to the exception thus created will be passed to catch. At the
 end of the catch block there's no outstanding reference to "obj" so it
 will be freed. All  nogc code must use this form of catch.

 If the catching code uses "catch (Exception obj)", the exception is
 cloned on the gc heap and then freed.

 Finally, if an exception is thrown with "throw new Exception" it can be
 caught with "catch (scope Exception obj)" by copying the exception from
 the heap into the special region, and then freeing the exception on the
 heap.

 Such a scheme preserves backward compatibility and leverages the work
 done on "scope".


 Andrei


I love it!

Could we also have some way to force scope when throwing?

interface ScoppedThrowable {}
class MyException : Exception, ScoppedThrowable { ... }

throw new MyException;
Apr 01 2017
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2017-04-01 15:34, Andrei Alexandrescu wrote:

 Walter and I discussed the following promising setup:

 Use "throw new scope Exception" from  nogc code. That will cause the
 exception to be allocated in a special stack-like region.

 If the catching code uses "catch (scope Exception obj)", then a
 reference to the exception thus created will be passed to catch. At the
 end of the catch block there's no outstanding reference to "obj" so it
 will be freed. All  nogc code must use this form of catch.

 If the catching code uses "catch (Exception obj)", the exception is
 cloned on the gc heap and then freed.

 Finally, if an exception is thrown with "throw new Exception" it can be
 caught with "catch (scope Exception obj)" by copying the exception from
 the heap into the special region, and then freeing the exception on the
 heap.

 Such a scheme preserves backward compatibility and leverages the work
 done on "scope".


Sounds interesting. Any more details about how the exception will be 
allocated.

-- 
/Jacob Carlborg
Apr 01 2017
prev sibling next sibling parent reply deadalnix <deadalnix gmail.com> writes:
On Saturday, 1 April 2017 at 13:34:58 UTC, Andrei Alexandrescu 
wrote:

 Walter and I discussed the following promising setup:

 Use "throw new scope Exception" from  nogc code. That will 
 cause the exception to be allocated in a special stack-like 
 region.

 If the catching code uses "catch (scope Exception obj)", then a 
 reference to the exception thus created will be passed to 
 catch. At the end of the catch block there's no outstanding 
 reference to "obj" so it will be freed. All  nogc code must use 
 this form of catch.

 If the catching code uses "catch (Exception obj)", the 
 exception is cloned on the gc heap and then freed.

 Finally, if an exception is thrown with "throw new Exception" 
 it can be caught with "catch (scope Exception obj)" by copying 
 the exception from the heap into the special region, and then 
 freeing the exception on the heap.

 Such a scheme preserves backward compatibility and leverages 
 the work done on "scope".


 Andrei


I'll repeat myself, even if I don't believe it'll be listened to 
at this point.

The problem you want to address is not GC allocations, it is GC 
collection cycles. If everything is freed, then there is no GC 
problem. not only this, but this is the only way GC and nogc code 
will interact with each others.

As long as a memory allocation has an owner the compiler can 
track, it can be freed explicitly, and, when it cannot, the 
compiler transfer ownership to the GC, which is illegal in  nogc 
code.

Transfering the ownership to the unwind handler when doing:

throw new FooException();

Is not rocket science and doesn't need any new language addition.

Now onto to scope. Scope essentially means that you are going to 
use some object without taking ownership of it. Indeed, in case 
of catch(Exception e) the language has to transfers the ownership 
of the Exception to the GC, which is the thing that should be 
illegal (not throwing). catch(scope Exception e) would work both 
with GC owned and runtime owned exception, and, because the 
runtime know what's up, it can explicitly free the exception when 
it exit the catch block (there is already a runtime call for 
that), in the case it owns it.

It doesn't need any kind of throw new scope Exception, and was 
proposed, literally, years ago during discussion around DIP25 and 
alike.

I urge you to reconsider the proposal that were made at the time. 
They solve all the problems you are discovering now, and more. 
And, while more complex that DIP25 alone, considering 
DIP25+DIP1000+this thing+the RC object thing, you are already in 
the zone where the "simple" approach is not so simple already.

Things are unfolding exactly as predicted at the time. Ad hoc 
solutions to various problems are proposed one by one and the 
overall complexity is growing much larger than initially proposed 
solutions.
Apr 01 2017
next sibling parent Eugene Wissner <belka caraus.de> writes:
On Saturday, 1 April 2017 at 14:54:21 UTC, deadalnix wrote:

 I'll repeat myself, even if I don't believe it'll be listened 
 to at this point.

 The problem you want to address is not GC allocations, it is GC 
 collection cycles. If everything is freed, then there is no GC 
 problem. not only this, but this is the only way GC and nogc 
 code will interact with each others.

 As long as a memory allocation has an owner the compiler can 
 track, it can be freed explicitly, and, when it cannot, the 
 compiler transfer ownership to the GC, which is illegal in 
  nogc code.

 Transfering the ownership to the unwind handler when doing:

 throw new FooException();

 Is not rocket science and doesn't need any new language 
 addition.

 Now onto to scope. Scope essentially means that you are going 
 to use some object without taking ownership of it. Indeed, in 
 case of catch(Exception e) the language has to transfers the 
 ownership of the Exception to the GC, which is the thing that 
 should be illegal (not throwing). catch(scope Exception e) 
 would work both with GC owned and runtime owned exception, and, 
 because the runtime know what's up, it can explicitly free the 
 exception when it exit the catch block (there is already a 
 runtime call for that), in the case it owns it.

 It doesn't need any kind of throw new scope Exception, and was 
 proposed, literally, years ago during discussion around DIP25 
 and alike.

 I urge you to reconsider the proposal that were made at the 
 time. They solve all the problems you are discovering now, and 
 more. And, while more complex that DIP25 alone, considering 
 DIP25+DIP1000+this thing+the RC object thing, you are already 
 in the zone where the "simple" approach is not so simple 
 already.

 Things are unfolding exactly as predicted at the time. Ad hoc 
 solutions to various problems are proposed one by one and the 
 overall complexity is growing much larger than initially 
 proposed solutions.


I also want to add that the syntax is ugly. A lot of work is 
being done on "scope" currently, but I don't understand why 
"scope" should appear now in every line of code: scope 
parameters, scope exceptions... How do I decide if I should use 
"new Exception" or "throw new scope Exception"? If it is a 
migration path and everyone should migrate to "new scope 
Exception", then "throw new scope Exception" is still one keyword 
longer than the simple "throw new Exception". Imho it would be 
better to change the way exceptions are allocated instead of 
making a complex language even more complex.
Apr 01 2017
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/1/2017 7:54 AM, deadalnix wrote:

 It doesn't need any kind of throw new scope Exception, and was proposed,
 literally, years ago during discussion around DIP25 and alike.


A link to that proposal would be appreciated.
Apr 01 2017
parent reply deadalnix <deadalnix gmail.com> writes:
On Saturday, 1 April 2017 at 22:08:27 UTC, Walter Bright wrote:

 On 4/1/2017 7:54 AM, deadalnix wrote:

 It doesn't need any kind of throw new scope Exception, and was 
 proposed,
 literally, years ago during discussion around DIP25 and alike.


 A link to that proposal would be appreciated.


The forum search isn't returning anything useful so I'm not sure 
how to get that link. However, it goes roughly as follow. Note 
that it's a solution to solve DIP25+DIP1000+RC+nogc exception and 
a sludge of other issues, and that comparing it to any of these 
independently will yield the obvious it is more complex. But that 
wouldn't be a fair comparison, as one should compare it to the 
sum of all these proposals, not to any of them independently.

The compiler already has the nothing of "unique" and use it to 
some extent, for instance to optimize pure functions and allow to 
do some magic with new allocations. The proposal relax and extend 
the concept of unique and make it explicit, via the type 
qualifier 'owned'. Going into the details here would take too 
long, so i'll just reference this paper ( 
https://www.microsoft.com/en-us/research/wp-content/uploads/2016/0

applicable to D.

The GC heap is currently composed of several islands. One island 
per thread + one shared island + one immutable island. The owned 
qualifier essentially enable to have more island, and each 
indirection tagged owned is a jump to another island. What's 
currently understood as "unique" by the compiler can be 
considered owned, which includes values returned from strongly 
pure functions and fresh new allocations.

Let's see how that apply to exceptions and the GC:
  - If a T is thrown, the runtime assumes GC ownership of the 
exception.
  - If a owned(T) is thrown, the runtime takes ownership of the 
exception (and of the graph of objects reachable from the 
exception.

When catching:
  - If the catch isn't scope or owned, then is is a "consume" 
operation. If the runtime had ownership of the exception, it 
transfers it to the GC.
  - If the catch is scope, then the runtime keeps ownership of the 
Exception. Exiting the catch block is going to destroy the 
Exception and the whole island associated with it.
  - 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.

The only operations that need to be disallowed in nogc code are 
consuming owned such as their ownership is transferred to the GC, 
in this case, catch blocks which aren't owned or scope.

This mechanism solves numerous other issues. Notably and non 
exhaustively:
  - General reduction in the amount of garbage created.
  - Ability to transfers ownership of data between thread safely 
(without cast to/from shared).
  - Safe std.parralelism .
  - Elaborate construction of shared and immutable objects.
  - Safe reference counting.
  - Safe "arena" style reference counting such as: 
https://www.youtube.com/watch?v=JfmTagWcqoE
  - Solves problems with collection ownership and alike.
Apr 02 2017
next sibling parent reply Nick B <nick.barbalich gmail.com> writes:
On Sunday, 2 April 2017 at 21:27:07 UTC, deadalnix wrote:

 On Saturday, 1 April 2017 at 22:08:27 UTC, Walter Bright wrote:

 On 4/1/2017 7:54 AM, deadalnix wrote:

 It doesn't need any kind of throw new scope Exception, and 
 was proposed,
 literally, years ago during discussion around DIP25 and alike.


 A link to that proposal would be appreciated.


 The forum search isn't returning anything useful so I'm not 
 sure how to get that link. However, it goes roughly as follow. 
 Note that it's a solution to solve DIP25+DIP1000+RC+nogc 
 exception and a sludge of other issues, and that comparing it 
 to any of these independently will yield the obvious it is more 
 complex. But that wouldn't be a fair comparison, as one should 
 compare it to the sum of all these proposals, not to any of 
 them independently.


[snip]

 This mechanism solves numerous other issues. Notably and non 
 exhaustively:
  - General reduction in the amount of garbage created.
  - Ability to transfers ownership of data between thread safely 
 (without cast to/from shared).
  - Safe std.parralelism.
  - Elaborate construction of shared and immutable objects.
  - Safe reference counting.
  - Safe "arena" style reference counting such as: 
 https://www.youtube.com/watch?v=JfmTagWcqoE
  - Solves problems with collection ownership and alike.


This silence is killing me!

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 ?

cheers Nick
Apr 03 2017
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Apr 05 2017
next sibling parent reply Meta <jared771 gmail.com> writes:
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
Apr 05 2017
parent Mike Parker <aldacron gmail.com> writes:
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.
Apr 05 2017
prev sibling parent reply deadalnix <deadalnix gmail.com> writes:
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.
Apr 05 2017
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Apr 05 2017
parent reply deadalnix <deadalnix gmail.com> writes:
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.
Apr 06 2017
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/6/17 9:05 AM, deadalnix wrote:

 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.


Persistent is best when it leads to palpable results. We seem to be in 
an impasse that is difficult to overcome: discussing complex language 
design matters is tenuous over forum communication, but investing effort 
upfront into a proposal that may not be approved is a high cost.

One thing that would be great to factor out of the conversation is the 
finger pointing and accusations. I have absolutely no doubt you have the 
best interests at heart. On our side, we are here to help the D 
community best we can. Yes, there are ideas we don't consider good to 
pursue, but that doesn't automatically make us neither malicious nor 
incompetent.

There is this whole "you are ignoring others' ideas" and "we demand that 
this is listened to" that is sadly quite harmful. There is not ignoring 
as much as the difficulty on working on someone else's rough idea, while 
they simultaneously refuse to flesh it out. Going by our design 
sensibilities we consider our take on Exception workable. We know how to 
pursue it, make a detailed DIP for it, accompany it with a proof of 
concept implementation, and deploy it. At the same time we have gathered 
a very hazy understanding of your ideas from a few posts lacking detail 
- posts that even you can't find, refer, and formalize. We don't think 
it's reasonable that you consider us at fault for not pursuing your ideas.


Andrei
Apr 06 2017
next sibling parent reply Olivier FAURE <olivier.faure epitech.eu> writes:
On Thursday, 6 April 2017 at 16:39:15 UTC, Andrei Alexandrescu 
wrote:

 On 4/6/17 9:05 AM, deadalnix wrote:
 There is this whole "you are ignoring others' ideas" and "we 
 demand that this is listened to" that is sadly quite harmful. 
 There is not ignoring as much as the difficulty on working on 
 someone else's rough idea, while they simultaneously refuse to 
 flesh it out.


I'm not saying you're wrong, but there's a different between 
saying "You should flesh out your idea" and "We're not going to 
respond formally before you submit a DIP".
Apr 06 2017
parent deadalnix <deadalnix gmail.com> writes:
On Thursday, 6 April 2017 at 16:56:10 UTC, Olivier FAURE wrote:

 I'm not saying you're wrong, but there's a different between 
 saying "You should flesh out your idea" and "We're not going to 
 respond formally before you submit a DIP".


Yes that's essentially my problem here.
Apr 07 2017
prev sibling next sibling parent Z42K0 <no no.no> writes:
There were multiple topic on the matter back then. This is one i 
have saved in my bookmarks. Others shouldn't be too hard to find.

https://forum.dlang.org/thread/kpgilxyyrrluxpepepcg forum.dlang.org
Apr 06 2017
prev sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Thursday, 6 April 2017 at 16:39:15 UTC, Andrei Alexandrescu 
wrote:

 There is not ignoring as much as the difficulty on working on 
 someone else's rough idea, while they simultaneously refuse to 
 flesh it out.


AKA: I had this idea/criticism on some thread that I'm not going 
to provide a link for and you should know exactly what I am 
talking about.
Apr 06 2017
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Thank you for posting this.

Figuring all this out thoroughly will take some time, so this is just first 
impressions.

1. we already have some of the benefits of the proposal because D has
transitive 
immutability

2. I'm looking for a solution where exceptions don't rely on the GC to the
point 
where the GC code doesn't even need to be linked in. This proposal appears to 
maintain a dependence on the GC.

3. It requires annotation of catch declarations with one of "", "scope", or 
"owned". I expect this would be a significant problem

4. Since the catch block is not type checked against the corresponding throw, 
the object will have to have noted in it who owns it.

5. The normal case is:

     throw new Exception("message");
     ...
     catch (Exception e) {
          writeln(e.msg);
     }

which would ideally work without involving the GC at all.

6. reducing the amount of GC garbage created is good, but does not solve the 
problem of "I don't want to use D because of the GC".

This proposal looks promising for making a better garbage collected language, 
but people want a language with an optional GC.
Apr 04 2017
next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 4 April 2017 at 09:45:14 UTC, Walter Bright wrote:

 6. reducing the amount of GC garbage created is good, but does 
 not solve the problem of "I don't want to use D because of the 
 GC".


I betcha D would be a better language with more users if you just 
told those people "sorry, it isn't for you then" and focused on 
improving what we already have.

I've never had a problem using D without a GC as it is now BTW. 
But that's because I'm more interested in getting work done than 
in endlessly whining about a language I don't even actually use 
or understand in Reddit comments.
Apr 04 2017
prev sibling parent reply deadalnix <deadalnix gmail.com> writes:
On Tuesday, 4 April 2017 at 09:45:14 UTC, Walter Bright wrote:

 1. we already have some of the benefits of the proposal because 
 D has transitive immutability


This works hand in hand with D type qualifier system.


 2. I'm looking for a solution where exceptions don't rely on 
 the GC to the point where the GC code doesn't even need to be 
 linked in. This proposal appears to maintain a dependence on 
 the GC.


Then just do:
auto ePtr = malloc(...);
auto e = *(cast(Exception*) &ePtr);
throw e;

Problem solved, you did not used the GC.

This proposal has nothing to do with Exceptions. It just happens 
to solve the Exception problem, just as it does for many others.

The problem people have with the GC isn't that it need to be 
linked in, it is that collection cycles create latency that 
doesn't work for their use case. If allocation are freed, then 
there is no GC problem.

Nobody is complaining that they cannot use C++ without its 
runtime. And for the 0.1% who actually need it, they just write 
custom allocation, and jump through a few hoops. This is a just 
good engineering. You are trying to solve the wrong problem.

really, in the process you are also murdering another legit use 
case that is orders of magnitude more common: library writers. 
They want to write code that'll work when the GC is used or not.


 3. It requires annotation of catch declarations with one of "", 
 "scope", or "owned". I expect this would be a significant 
 problem


This proposal just add the owned type qualifier. scope already 
exists. It solves many problem for which new syntax have been 
introduced, so it's rather rich.

"I don't want this proposal that add one new syntax, I'd rather 
have 4 smaller proposals that each add a new syntax."


 4. Since the catch block is not type checked against the 
 corresponding throw, the object will have to have noted in it 
 who owns it.


throw never leaks, so there is no point in checking the throw. 
You already throw something that is owned by the GC, in which 
case you leaked earlier, or you transfer the ownership to the 
runtime and you haven't leaked yet.

Because throw never leaks, there is no point in butchering throw 
to make it compatible with nogc.

Back to the catch block, the question is the same as for a 
function call or anything else really. It either borrow the 
exception (scope) take ownership of it (owned) or just delegate 
the work to the GC.


 5. The normal case is:

     throw new Exception("message");
     ...
     catch (Exception e) {
          writeln(e.msg);
     }

 which would ideally work without involving the GC at all.


This cannot be nogc in the general case because e can be 
reassigned to anything that is owned by the GC. In that specific 
case, scope can be inferred.


 6. reducing the amount of GC garbage created is good, but does 
 not solve the problem of "I don't want to use D because of the 
 GC".

 This proposal looks promising for making a better garbage 
 collected language, but people want a language with an optional 
 GC.


If you have guarantee that you won't leak, and so will never run 
collection cycle, you don't have a GC, you effectively have 
malloc and free. There is no need to butcher the language because 
there are morons on the internet. really that's hardly newsworthy.
Apr 04 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Apr 05 2017
parent reply deadalnix <deadalnix gmail.com> writes:
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.
Apr 05 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.




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.
Apr 05 2017
parent reply deadalnix <deadalnix gmail.com> writes:
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.






 deliver the promised results enough to justify its cost?


In D, the cost/benefit ratio is higher because it solves problems 

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.
Apr 06 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/6/2017 6:32 AM, deadalnix wrote:

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


When referencing previous discussions, please include a link. Having people 
guess at where such discussion took place (github? wiki? bugzilla? n.g.? IRC? 
DConf?), and which thread it might be, is not helpful. The last time upthread I 
tried to find one such you referred to I came up empty-handed.
Apr 06 2017
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Apr 06, 2017 at 12:54:40PM -0700, Walter Bright via Digitalmars-d wrote:

 On 4/6/2017 6:32 AM, deadalnix wrote:

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


 
 When referencing previous discussions, please include a link. Having
 people guess at where such discussion took place (github? wiki?
 bugzilla? n.g.?  IRC? DConf?), and which thread it might be, is not
 helpful. The last time upthread I tried to find one such you referred
 to I came up empty-handed.


Try this for starters:

	https://forum.dlang.org/thread/kpgilxyyrrluxpepepcg forum.dlang.org?page=1


T

-- 
The best way to destroy a cause is to defend it poorly.
Apr 06 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/6/2017 1:23 PM, H. S. Teoh via Digitalmars-d wrote:

 On Thu, Apr 06, 2017 at 12:54:40PM -0700, Walter Bright via Digitalmars-d
wrote:

 On 4/6/2017 6:32 AM, deadalnix wrote:

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


 When referencing previous discussions, please include a link. Having
 people guess at where such discussion took place (github? wiki?
 bugzilla? n.g.?  IRC? DConf?), and which thread it might be, is not
 helpful. The last time upthread I tried to find one such you referred
 to I came up empty-handed.


 Try this for starters:

 	https://forum.dlang.org/thread/kpgilxyyrrluxpepepcg forum.dlang.org?page=1


deadalnix?
Apr 06 2017
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Apr 06, 2017 at 02:07:52PM -0700, Walter Bright via Digitalmars-d wrote:

 On 4/6/2017 1:23 PM, H. S. Teoh via Digitalmars-d wrote:

 On Thu, Apr 06, 2017 at 12:54:40PM -0700, Walter Bright via Digitalmars-d
wrote:

 On 4/6/2017 6:32 AM, deadalnix wrote:

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


 
 When referencing previous discussions, please include a link.
 Having people guess at where such discussion took place (github?
 wiki?  bugzilla? n.g.?  IRC? DConf?), and which thread it might
 be, is not helpful. The last time upthread I tried to find one
 such you referred to I came up empty-handed.


 
 Try this for starters:
 
 	https://forum.dlang.org/thread/kpgilxyyrrluxpepepcg forum.dlang.org?page=1


 
 deadalnix?


You were asking for a link to deadalnix's original discussion, and
that's the link I found (somebody else also posted a link to the same
discussion).

He also alluded to the "lifetime ML", I'm not 100% sure but I think he
may have been referring to these discussions (or related ones in the
same mailing list):

	http://forum.dlang.org/thread/56301A8C.1060808 erdani.com

(Sorry I couldn't pull up a more specific link, my office network's
corporate firewall has completely hosed SSL negotiations so google
doesn't work anymore as they've switched to SSL by default.)


T

-- 
In theory, there is no difference between theory and practice.
Apr 06 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/6/2017 2:18 PM, H. S. Teoh via Digitalmars-d wrote:

 You were asking for a link to deadalnix's original discussion, and
 that's the link I found (somebody else also posted a link to the same
 discussion).


Only deadalnix can confirm that's what he's talking about.
Apr 06 2017
parent reply deadalnix <deadalnix gmail.com> writes:
On Thursday, 6 April 2017 at 22:11:55 UTC, Walter Bright wrote:

 On 4/6/2017 2:18 PM, H. S. Teoh via Digitalmars-d wrote:

 You were asking for a link to deadalnix's original discussion, 
 and
 that's the link I found (somebody else also posted a link to 
 the same
 discussion).


 Only deadalnix can confirm that's what he's talking about.


Yes this: 
https://forum.dlang.org/thread/kpgilxyyrrluxpepepcg forum.dlang.org
Also this: 
https://forum.dlang.org/post/kluaojijixhwigoujeip forum.dlang.org

I also produced a fairly detailed spec of how lifetime can be 
tracked in the lifetime ML. This address scope and do not require 
owned by itself. Considering the compiler infer what it calls 
"unique" already, it could solve the  nogc Exception problem to 
some extent without the owned part. Because it is in a ML, I 
cannot post a link.
Apr 07 2017
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2017-04-07 18:30, deadalnix wrote:


 Because it is in a ML, I cannot post a link.


Is it this mailing list: http://forum.dlang.org/group/study ?

-- 
/Jacob Carlborg
Apr 08 2017
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/7/2017 9:30 AM, deadalnix wrote:

 On Thursday, 6 April 2017 at 22:11:55 UTC, Walter Bright wrote:

 On 4/6/2017 2:18 PM, H. S. Teoh via Digitalmars-d wrote:

 You were asking for a link to deadalnix's original discussion, and
 that's the link I found (somebody else also posted a link to the same
 discussion).


 Only deadalnix can confirm that's what he's talking about.


 Yes this: https://forum.dlang.org/thread/kpgilxyyrrluxpepepcg forum.dlang.org
 Also this: https://forum.dlang.org/post/kluaojijixhwigoujeip forum.dlang.org


Some convenient single page links:

http://www.digitalmars.com/d/archives/digitalmars/D/On_heap_segregation_GC_optimization_and_nogc_relaxing_247498.html

http://www.digitalmars.com/d/archives/digitalmars/D/isolated_owned_would_solve_many_problem_we_face_right_now._212165.html



 I also produced a fairly detailed spec of how lifetime can be tracked in the
 lifetime ML. This address scope and do not require owned by itself. Considering
 the compiler infer what it calls "unique" already, it could solve the  nogc
 Exception problem to some extent without the owned part. Because it is in a ML,
 I cannot post a link.


Please repost it somewhere and a link. It's not very practical to refer to 
documents nobody is able to read.
Apr 08 2017
parent reply Christophe <travert phare.normalesup.org> writes:
On Saturday, 8 April 2017 at 20:09:49 UTC, Walter Bright wrote:

 On 4/7/2017 9:30 AM, deadalnix wrote:

 On Thursday, 6 April 2017 at 22:11:55 UTC, Walter Bright wrote:

 On 4/6/2017 2:18 PM, H. S. Teoh via Digitalmars-d wrote:

 You were asking for a link to deadalnix's original 
 discussion, and
 that's the link I found (somebody else also posted a link to 
 the same
 discussion).


 Only deadalnix can confirm that's what he's talking about.


 Yes this: 
 https://forum.dlang.org/thread/kpgilxyyrrluxpepepcg forum.dlang.org
 Also this: 
 https://forum.dlang.org/post/kluaojijixhwigoujeip forum.dlang.org


 Some convenient single page links:

 http://www.digitalmars.com/d/archives/digitalmars/D/On_heap_segregation_GC_optimization_and_nogc_relaxing_247498.html

 http://www.digitalmars.com/d/archives/digitalmars/D/isolated_owned_would_solve_many_problem_we_face_right_now._212165.html



 I also produced a fairly detailed spec of how lifetime can be 
 tracked in the
 lifetime ML. This address scope and do not require owned by 
 itself. Considering
 the compiler infer what it calls "unique" already, it could 
 solve the  nogc
 Exception problem to some extent without the owned part. 
 Because it is in a ML,
 I cannot post a link.


 Please repost it somewhere and a link. It's not very practical 
 to refer to documents nobody is able to read.


My dog ate my homework.

deadalnix's a genius of marketing. He has no product, all he 
invested was a couple afternoons in newsgroup posts edging on 
rants. It's impossible to convert the incomplete ideas that he 
throws over the fence into spec and code. But he sells them as 
the perfect product. That the posts are incomplete and unclear 
helps because whatever problem has a solution in the future. What 
amazes me is he still grabs the attention of newbies in the forum.
Apr 08 2017
parent reply Shachar Shemesh <shachar weka.io> writes:
On 09/04/17 00:35, Christophe wrote:


 My dog ate my homework.

 deadalnix's a genius of marketing. He has no product, all he invested
 was a couple afternoons in newsgroup posts edging on rants. It's
 impossible to convert the incomplete ideas that he throws over the fence
 into spec and code. But he sells them as the perfect product. That the
 posts are incomplete and unclear helps because whatever problem has a
 solution in the future. What amazes me is he still grabs the attention
 of newbies in the forum.


It seems to me you are posting this after the homework have already been 
found. To me, said homework even seem to have merit, though I 
acknowledge you might disagree.

Personally, I think keeping things about the proposals rather than about 
the person would be more beneficial to the language at large.

Shachar
Apr 09 2017
parent reply irritate <irritate gmail.com> writes:
On Sunday, 9 April 2017 at 07:56:08 UTC, Shachar Shemesh wrote:

 On 09/04/17 00:35, Christophe wrote:


 My dog ate my homework.

 deadalnix's a genius of marketing. He has no product, all he 
 invested
 was a couple afternoons in newsgroup posts edging on rants. 
 It's
 impossible to convert the incomplete ideas that he throws over 
 the fence
 into spec and code. But he sells them as the perfect product. 
 That the
 posts are incomplete and unclear helps because whatever 
 problem has a
 solution in the future. What amazes me is he still grabs the 
 attention
 of newbies in the forum.


 It seems to me you are posting this after the homework have 
 already been found. To me, said homework even seem to have 
 merit, though I acknowledge you might disagree.


His "detailed proposal" in the mailing list is not yet recovered. 
  Perhaps Symantec owns the license.


 Personally, I think keeping things about the proposals rather 
 than about the person would be more beneficial to the language 
 at large.


The problems is with the so called "proposals".  Second class 
ideas nowhere near implementation. There is a better discussion 
in this forum, every other week.  Deadalinx should get a better 
image of the quality of his own work and stop shamelessly touting 
it.

irritate
Apr 09 2017
parent reply deadalnix <deadalnix gmail.com> writes:
On Sunday, 9 April 2017 at 13:16:45 UTC, irritate wrote:

 The problems is with the so called "proposals".  Second class 
 ideas nowhere near implementation. There is a better discussion 
 in this forum, every other week.  Deadalinx should get a better 
 image of the quality of his own work and stop shamelessly 
 touting it.

 irritate


 From you, I'm taking it as a compliment. Thanks.
Apr 09 2017
parent KaattuPoochi <visionofarun gmail.com> writes:
On Sunday, 9 April 2017 at 15:57:39 UTC, deadalnix wrote:

 On Sunday, 9 April 2017 at 13:16:45 UTC, irritate wrote:

 The problems is with the so called "proposals".  Second class 
 ideas nowhere near implementation. There is a better 
 discussion in this forum, every other week.  Deadalinx should 
 get a better image of the quality of his own work and stop 
 shamelessly touting it.

 irritate


 From you, I'm taking it as a compliment. Thanks.


deadalnix please open source your work!
Apr 09 2017
prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Saturday, 1 April 2017 at 14:54:21 UTC, deadalnix wrote:

 The problem you want to address is not GC allocations, it is GC 
 collection cycles. If everything is freed, then there is no GC 
 problem. not only this, but this is the only way GC and nogc 
 code will interact with each others.


Amen. Moreover, for little things like exceptions, you can 
probably also just hack it to not do a collection cycle when 
allocating them.

pseudocode:

So right now, we have:

void* gc_alloc(T)(size_t sz) {
     auto alloc = malloc(sz);
     if(alloc is null) {
        collection_cycle();
        retry();
        if(alloc is null) // still
           onOutOfMemoryError();
     }
     return alloc;
}

But imagine if it was

     if(alloc is null && !is(T : Throwable))


so it just abort()'s if it can't allocate the exception instead 
of collecting. How would that be any different than malloc()'ing 
it?

But, if you DO get a chance to run the GC, it will be collected, 
and, of course, you can manually/automatically free it too.

Works with existing code with no more likelyhood of leaking than 
we already have, maintaining memory safety... and removes the 
risk of a new exception of triggering a gc cycle.

so why not?


 Things are unfolding exactly as predicted at the time. Ad hoc 
 solutions to various problems are proposed one by one and the 
 overall complexity is growing much larger than initially 
 proposed solutions.


Yeah, my gut reaction to this was "gross moar attributes come on"
Apr 01 2017
parent reply Johannes Pfau <nospam example.com> writes:
Am Sun, 02 Apr 2017 00:09:09 +0000
schrieb Adam D. Ruppe <destructionator gmail.com>:


 On Saturday, 1 April 2017 at 14:54:21 UTC, deadalnix wrote:

 The problem you want to address is not GC allocations, it is GC 
 collection cycles. If everything is freed, then there is no GC 
 problem. not only this, but this is the only way GC and nogc 
 code will interact with each others.  


 
 Amen. Moreover, for little things like exceptions, you can 
 probably also just hack it to not do a collection cycle when 
 allocating them.


I do not want GC _allocation_ for embedded systems (don't even
want to link in the GC or GC stub code) ;-)


-- Johannes
Apr 02 2017
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Sunday, 2 April 2017 at 18:16:43 UTC, Johannes Pfau wrote:

 I do not want GC _allocation_ for embedded systems (don't even
 want to link in the GC or GC stub code) ;-)


Then don't use operator `new`... you're probably using some kind 
of custom druntime anyway.
Apr 02 2017
parent deadalnix <deadalnix gmail.com> writes:
On Sunday, 2 April 2017 at 18:41:45 UTC, Adam D. Ruppe wrote:

 On Sunday, 2 April 2017 at 18:16:43 UTC, Johannes Pfau wrote:

 I do not want GC _allocation_ for embedded systems (don't even
 want to link in the GC or GC stub code) ;-)


 Then don't use operator `new`... you're probably using some 
 kind of custom druntime anyway.


Yes I think it is fair to assume one will have to jump through 
some hoops if one doesn't use want to use the runtime. That's 
fine.
Apr 02 2017
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/1/2017 7:54 AM, deadalnix wrote:

 The problem you want to address is not GC allocations, it is GC collection
 cycles. If everything is freed, then there is no GC problem. not only this, but
 this is the only way GC and nogc code will interact with each others.


This does not address the stated need (by many programmers) to not even have to 
link in the GC code. A solution that falls short of this will be rejected. The 
rejections may not be technically well founded, but we're not in a good
position 
to try to educate the masses on this. A solution that does not require linking 
to the GC sidesteps that problem.



 As long as a memory allocation has an owner the compiler can track, it can be
 freed explicitly, and, when it cannot, the compiler transfer ownership to the
 GC, which is illegal in  nogc code.

 Transfering the ownership to the unwind handler when doing:

 throw new FooException();

 Is not rocket science and doesn't need any new language addition.


There's also:

    auto e = someFunctionThatReturnsAnException();
    throw e;

where who owns it or how it was allocated is not clear at all.

Other issues that need attention are:

1. chaining exceptions
2. rethrowing



 Now onto to scope. Scope essentially means that you are going to use some
object
 without taking ownership of it. Indeed, in case of catch(Exception e) the
 language has to transfers the ownership of the Exception to the GC, which is
the
 thing that should be illegal (not throwing). catch(scope Exception e) would
work
 both with GC owned and runtime owned exception, and, because the runtime know
 what's up, it can explicitly free the exception when it exit the catch block
 (there is already a runtime call for that), in the case it owns it.


'scope' is indeed a critical factor in making this work.



 It doesn't need any kind of throw new scope Exception, and was proposed,
 literally, years ago during discussion around DIP25 and alike.

 I urge you to reconsider the proposal that were made at the time. They solve
all
 the problems you are discovering now, and more. And, while more complex that
 DIP25 alone, considering DIP25+DIP1000+this thing+the RC object thing, you are
 already in the zone where the "simple" approach is not so simple already.


I did some searching for this previous proposal discussion, but could not find 
it. Instead, I'll go by your description of it here.

I've written a more fleshed out proposal and started a new thread with it. Feel 
free to rip it to shreds!
Apr 01 2017
prev sibling next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 4/1/17 3:34 PM, Andrei Alexandrescu wrote:

 Walter and I discussed the following promising setup:

 Use "throw new scope Exception" from  nogc code. That will cause the
 exception to be allocated in a special stack-like region.

 If the catching code uses "catch (scope Exception obj)", then a
 reference to the exception thus created will be passed to catch. At the
 end of the catch block there's no outstanding reference to "obj" so it
 will be freed. All  nogc code must use this form of catch.

 If the catching code uses "catch (Exception obj)", the exception is
 cloned on the gc heap and then freed.

 Finally, if an exception is thrown with "throw new Exception" it can be
 caught with "catch (scope Exception obj)" by copying the exception from
 the heap into the special region, and then freeing the exception on the
 heap.


Horrible. Introducing the verbose way for the most commonly useful 
scenario and pushing the complexity on to programmers.

I don't understand what's so difficult to just recognize that "throw new 
Exception" creates a unique object that is passed to the exception 
handler. So just mark the exception as unique in the exception handler 
code so that catch site is aware of it. Are we just bend on penalizing 
programmers for not typing out "scope"?

In turn I don't see what adding "scope" to the catch site accomplishes 
- you still need to ensure the reference doesn't escape. And if it 
doesn't escape you may just as well deallocate the exception object.


 Such a scheme preserves backward compatibility and leverages the work
 done on "scope".


Pardon but I don't see how. It has one good thing going for it - the 
same keyword.


---
Dmitry Olshansky

 Andrei
Apr 01 2017
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/1/17 2:18 PM, Dmitry Olshansky wrote:

 I don't understand what's so difficult to just recognize that "throw new
 Exception" creates a unique object that is passed to the exception
 handler.


That would be a good possibility: default to creating exceptions as 
scope objects, speculating that the catch site may also be scope. If the 
catch site does not use scope, then clone into a heap object. This is 
speculative, but the cost of cloning is much smaller than the cost of 
the allocation so it's not a large loss.


 So just mark the exception as unique in the exception handler
 code so that catch site is aware of it. Are we just bend on penalizing
 programmers for not typing out "scope"?


A catch site that does not use "scope" has more freedom, e.g.:

void fun()
{
     static Exception last;
     try { ... }
     catch (Exception e) { last = e; }
     ...
}

Such is not possible with a scoped catch. Of course, that's a concern 
only if we want to preserve backwards compatibility.


 In turn I don't see what adding "scope" to the catch site accomplishes -
 you still need to ensure the reference doesn't escape.


You don't. Old code behaves as it always did.


 And if it doesn't
 escape you may just as well deallocate the exception object.


Ah, so here we're looking at a deduction scheme. Most interesting! First 
try to see if "scope" would work (even if not written), and if so just 
consider it there.


 Such a scheme preserves backward compatibility and leverages the work
 done on "scope".


 Pardon but I don't see how.


Think again - checks and e.g. deduction (if we add it as you suggested 
above) would work pretty much out of the box.


Andrei
Apr 02 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/2/2017 10:21 AM, Andrei Alexandrescu wrote:

 Such is not possible with a scoped catch. Of course, that's a concern only if
we
 want to preserve backwards compatibility.


That can be done if the user makes a clone of 'e' (I don't propose the compiler 
do this automatically).



 In turn I don't see what adding "scope" to the catch site accomplishes -
 you still need to ensure the reference doesn't escape.


 You don't. Old code behaves as it always did.


 And if it doesn't
 escape you may just as well deallocate the exception object.


 Ah, so here we're looking at a deduction scheme. Most interesting! First try to
 see if "scope" would work (even if not written), and if so just consider it
there.


 Such a scheme preserves backward compatibility and leverages the work
 done on "scope".


 Pardon but I don't see how.


 Think again - checks and e.g. deduction (if we add it as you suggested above)
 would work pretty much out of the box.


The compiler can definitely deduce the 'scope' for the catch object, and if it 
is, insert code to free it at the close of the catch. But that has problems:

1. If the thrown object was not allocated with the GC (such as if it was 
'emplaced'), then doing a GC free on it at the catch site will corrupt memory.

2. There isn't an indication to the user if it is free'd or not at the close of 
the catch.

3. The GC code still has to be linked in.

4. The throw site still cannot be marked as  nogc.
Apr 02 2017
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
Walter Bright wrote:


 1. If the thrown object was not allocated with the GC (such as if it was 
 'emplaced'), then doing a GC free on it at the catch site will corrupt 
 memory.


no, it won't. it is completely safe to free non-GC-owned memory with GC[0].

[0] http://dpldocs.info/experimental-docs/core.memory.GC.free.html
Apr 02 2017
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/2/2017 2:05 PM, ketmar wrote:

 Walter Bright wrote:


 1. If the thrown object was not allocated with the GC (such as if it was
 'emplaced'), then doing a GC free on it at the catch site will corrupt memory.


 no, it won't. it is completely safe to free non-GC-owned memory with GC[0].

 [0] http://dpldocs.info/experimental-docs/core.memory.GC.free.html


Yes, you're right.
Apr 02 2017
prev sibling parent Martin Nowak <code dawg.eu> writes:
On Sunday, 2 April 2017 at 21:05:39 UTC, ketmar wrote:

 no, it won't. it is completely safe to free non-GC-owned memory 
 with GC[0].

 [0] 
 http://dpldocs.info/experimental-docs/core.memory.GC.free.html


At the cost of a GC mutex lock and metadata lookup, not too 
horrible, but not free either.
Apr 08 2017
prev sibling next sibling parent reply Guillaume Piolat <first.last gmail.com> writes:
On Saturday, 1 April 2017 at 13:34:58 UTC, Andrei Alexandrescu 
wrote:

 Walter and I discussed the following promising setup:

 Use "throw new scope Exception" from  nogc code. That will 
 cause the exception to be allocated in a special stack-like 
 region.

 If the catching code uses "catch (scope Exception obj)", then a 
 reference to the exception thus created will be passed to 
 catch. At the end of the catch block there's no outstanding 
 reference to "obj" so it will be freed. All  nogc code must use 
 this form of catch.

 If the catching code uses "catch (Exception obj)", the 
 exception is cloned on the gc heap and then freed.

 Finally, if an exception is thrown with "throw new Exception" 
 it can be caught with "catch (scope Exception obj)" by copying 
 the exception from the heap into the special region, and then 
 freeing the exception on the heap.

 Such a scheme preserves backward compatibility and leverages 
 the work done on "scope".


 Andrei


(currently using  nogc exceptions with malloc+emplace and 
destroy+free)

OK. The important bit imho is that exception don't become special 
class objects.
ie. "scope new" is not specific to exceptions.
The other  nogc blocker is .destroy
Apr 01 2017
next sibling parent reply Eugene Wissner <belka caraus.de> writes:
On Saturday, 1 April 2017 at 18:56:56 UTC, Guillaume Piolat wrote:

 (currently using  nogc exceptions with malloc+emplace and 
 destroy+free)

 OK. The important bit imho is that exception don't become 
 special class objects.
 ie. "scope new" is not specific to exceptions.
 The other  nogc blocker is .destroy


If I understand correctly exceptions are anyway special class 
objects. A scope Exception wouldn't be allocated in the current 
scope, but elsewhere, so it can be catched outside the current 
stack frame. The same as Errors are special class objects, they 
can be thrown regardless nothrow and  nogc, because these aren't 
recoverable errors.
Apr 01 2017
parent Adam D. Ruppe <destructionator gmail.com> writes:
On Saturday, 1 April 2017 at 19:52:14 UTC, Eugene Wissner wrote:

 If I understand correctly exceptions are anyway special class 
 objects.


No, exceptions are just ordinary objects, they just happen to 
inherit from Throwable which is the interface the compiler 
requires for the `throw` statement.


 The same as Errors are special class objects, they can be 
 thrown regardless nothrow and  nogc, because these aren't 
 recoverable errors.


 nogc doesn't prevent throwing anything, you can throw an 
Exception in it too.

But indeed, Error is exempt from nothrow but other than that, it 
is also just a normal class.
Apr 01 2017
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/1/17 2:56 PM, Guillaume Piolat wrote:

 The other  nogc blocker is .destroy


How do you mean that? -- Andrei
Apr 02 2017
parent reply Guillaume Piolat <first.last gmail.com> writes:
On Sunday, 2 April 2017 at 17:22:11 UTC, Andrei Alexandrescu 
wrote:

 On 4/1/17 2:56 PM, Guillaume Piolat wrote:

 The other  nogc blocker is .destroy


 How do you mean that? -- Andrei


https://github.com/dlang/druntime/blob/master/src/object.d#L2732

destroy() infers it's " nogc"-ness from rt_finalize which is not 
nothrow and not  nogc:
https://github.com/dlang/druntime/blob/5a94816c8f1d5c225e560151cebe0a09949896a5/src/object.d#L16

I guess the rationale is that rt_finalize call Object.~this() and 
that may GC allocate, and throw.

In turn this cause every wrapper using emplace+destroy to not be 
 nogc.
Apr 02 2017
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/2/17 4:21 PM, Guillaume Piolat wrote:

 On Sunday, 2 April 2017 at 17:22:11 UTC, Andrei Alexandrescu wrote:

 On 4/1/17 2:56 PM, Guillaume Piolat wrote:

 The other  nogc blocker is .destroy


 How do you mean that? -- Andrei


 https://github.com/dlang/druntime/blob/master/src/object.d#L2732

 destroy() infers it's " nogc"-ness from rt_finalize which is not nothrow
 and not  nogc:
 https://github.com/dlang/druntime/blob/5a94816c8f1d5c225e560151cebe0a09949896a5/src/object.d#L16


 I guess the rationale is that rt_finalize call Object.~this() and that
 may GC allocate, and throw.

 In turn this cause every wrapper using emplace+destroy to not be  nogc.


Got it. Could you please create an issue about this? -- Andrei
Apr 03 2017
parent Guillaume Piolat <first.last gmail.com> writes:
On Monday, 3 April 2017 at 21:28:39 UTC, Andrei Alexandrescu 
wrote:

 Got it. Could you please create an issue about this? -- Andrei


Sure.
https://issues.dlang.org/show_bug.cgi?id=17297
Apr 04 2017
prev sibling parent reply Matthias Bentrup <matthias.bentrup googlemail.com> writes:
On Saturday, 1 April 2017 at 13:34:58 UTC, Andrei Alexandrescu 
wrote:

 Walter and I discussed the following promising setup:

 Use "throw new scope Exception" from  nogc code. That will 
 cause the exception to be allocated in a special stack-like 
 region.

 If the catching code uses "catch (scope Exception obj)", then a 
 reference to the exception thus created will be passed to 
 catch. At the end of the catch block there's no outstanding 
 reference to "obj" so it will be freed. All  nogc code must use 
 this form of catch.

 If the catching code uses "catch (Exception obj)", the 
 exception is cloned on the gc heap and then freed.

 Finally, if an exception is thrown with "throw new Exception" 
 it can be caught with "catch (scope Exception obj)" by copying 
 the exception from the heap into the special region, and then 
 freeing the exception on the heap.

 Such a scheme preserves backward compatibility and leverages 
 the work done on "scope".


 Andrei


How would you deal with the Exception payload, e.g. the message 
string ? If I have to place it on the heap, I lose  nogc, if I 
place it in the local scope, it will be destroyed before the 
Exception handler is called and if I restrict the mechanism to 
fixed payloads, I could have used static Exception objects in the 
first place.

It may be possible to copy the message string from local scope to 
the special stack on throw, but in the general case the payload 
could be an arbitrary tree of Objects allocated on the heap or 
the stack, or even on the special exception stack itself.

A method I used to pass scope data up the stack is by using 
"thrower delegates", i.e. the  nogc throwing function doesn't 
directly throw an Exception, but it calls a delegate that is 
passed all the payloads as arguments and which throws a static 
Exception.

This thrower delegate is provided by the Exception catching 
function, and has the opportunity to read/copy the parts of the 
payload it is interested in before the stack is unwound.
Apr 03 2017
parent deadalnix <deadalnix gmail.com> writes:
On Monday, 3 April 2017 at 08:22:41 UTC, Matthias Bentrup wrote:

 How would you deal with the Exception payload, e.g. the message 
 string ?


Yes current proposal are unable to handle properly multiple 
levels of indirections.
Apr 03 2017