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
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
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
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
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
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
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 /msr-tr-2012-79.pdf ) for detailed work in C# about this. This is easily 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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. 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.
Apr 05
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.
 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.
Apr 06
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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