digitalmars.D - nogc
- Manu via Digitalmars-d (9/9) Jul 10 2014 So, we allow assert() in nothrow functions, the argument is that
- Kapps (6/18) Jul 10 2014 More generally, I'm somewhat surprised that @nogc does not still
- Piotr Szturman (3/21) Jul 12 2014 It does matter when entire program is marked with @nogc, so there may be...
- "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> (7/36) Jul 12 2014 Well, it wouldn't even link then...
- Walter Bright (4/13) Jul 10 2014 I've thought of allowing "throw new ...", and yours would be in addition...
- Chris Cain (25/28) Jul 10 2014 Errors I agree with (basically, that's the end of your program,
- Kapps (13/41) Jul 10 2014 I somewhat remember discussion about this originally during the
- Philpax (58/58) Jul 10 2014 I've run into my own series of trials and tribulations with a
- Andrei Alexandrescu (3/8) Jul 10 2014 [snip]
- Philpax (4/15) Jul 11 2014 Will do once I get back to work on that project and come up with
- Chris Cain (23/35) Jul 10 2014 Frankly, if there were absolutely no possibilities of workaround,
- H. S. Teoh via Digitalmars-d (5/25) Jul 11 2014 Wouldn't @reallynogc == @nogc + nothrow ?
- Chris Cain (8/9) Jul 11 2014 Not precisely. Throwing is perfectly fine in @reallynogc. You
- H. S. Teoh via Digitalmars-d (15/24) Jul 11 2014 Good point. I retract what I said.
- Manu via Digitalmars-d (6/25) Jul 10 2014 Well upon updating to 2.066b, the first thing I did was to spam @nogc
- Manu via Digitalmars-d (7/26) Jul 10 2014 I should add, I'm not sure I see that my case should be 'in addition'.
- Philpax (7/43) Jul 10 2014 I also have misgivings about this - while it's the easiest
- Andrei Alexandrescu (3/8) Jul 10 2014 Yah, I'd be hoping that @nogc guarantees you can actually not link the
- ponce (4/18) Jul 11 2014 Would be great to be able to speficify a custom allocator to
- bearophile (8/37) Jul 11 2014 It's true that currently significant parts of Phobos can't be
- Dicebot (6/9) Jul 11 2014 One can replace throwing of Error with printf + abort in @nogc
- Dicebot (2/11) Jul 11 2014 *throwing _new_ exceptions
- Joseph Rushton Wakeling (6/9) Jul 11 2014 I've habitually used 'format' to prepare assert messages with
- bearophile (7/11) Jul 11 2014 A solution is to add to Phobos a way to format to an output
- Chris Cain (18/29) Jul 11 2014 Although I think that is certainly something that would be
- Chris Cain (7/8) Jul 11 2014 Actually, thinking about this more, it's possible if the array of
- bearophile (5/9) Jul 11 2014 That function exists already, it just needs to become @nogc, I
So, we allow assert() in nothrow functions, the argument is that assert is non-recoverable, so it's distinct from user exceptions. I have this in my 'nothrow nogc' function: assert(false, "Message " ~ details); It complains "Error: cannot use operator ~ in nogc function" I think it should be allowed to invoke the GC for formatting error messages inside of assert statements, just the same as assert() is allowed inside of nothrow functions. Thoughts?
Jul 10 2014
On Friday, 11 July 2014 at 02:32:00 UTC, Manu via Digitalmars-d wrote:So, we allow assert() in nothrow functions, the argument is that assert is non-recoverable, so it's distinct from user exceptions. I have this in my 'nothrow nogc' function: assert(false, "Message " ~ details); It complains "Error: cannot use operator ~ in nogc function" I think it should be allowed to invoke the GC for formatting error messages inside of assert statements, just the same as assert() is allowed inside of nothrow functions. Thoughts?More generally, I'm somewhat surprised that nogc does not still allow allocating Errors (including with assert), as who cares if your program may slightly pause when it's about to crash in a theoretically unrecoverable way.
Jul 10 2014
W dniu 2014-07-11 05:18, Kapps pisze:On Friday, 11 July 2014 at 02:32:00 UTC, Manu via Digitalmars-d wrote:It does matter when entire program is marked with nogc, so there may be no GC code at all (GC code may not be linked).So, we allow assert() in nothrow functions, the argument is that assert is non-recoverable, so it's distinct from user exceptions. I have this in my 'nothrow nogc' function: assert(false, "Message " ~ details); It complains "Error: cannot use operator ~ in nogc function" I think it should be allowed to invoke the GC for formatting error messages inside of assert statements, just the same as assert() is allowed inside of nothrow functions. Thoughts?More generally, I'm somewhat surprised that nogc does not still allow allocating Errors (including with assert), as who cares if your program may slightly pause when it's about to crash in a theoretically unrecoverable way.
Jul 12 2014
On Saturday, 12 July 2014 at 09:44:16 UTC, Piotr Szturman wrote:W dniu 2014-07-11 05:18, Kapps pisze:Well, it wouldn't even link then... But I think the more common route to go in such a case is to make a stubbed out GC that provides only allocation functionality (e.g. forwarding to malloc/free), but doesn't do any garbage collection. After all, some kind of memory allocation needs to present in almost all cases, it's just that it's done manually.On Friday, 11 July 2014 at 02:32:00 UTC, Manu via Digitalmars-d wrote:It does matter when entire program is marked with nogc, so there may be no GC code at all (GC code may not be linked).So, we allow assert() in nothrow functions, the argument is that assert is non-recoverable, so it's distinct from user exceptions. I have this in my 'nothrow nogc' function: assert(false, "Message " ~ details); It complains "Error: cannot use operator ~ in nogc function" I think it should be allowed to invoke the GC for formatting error messages inside of assert statements, just the same as assert() is allowed inside of nothrow functions. Thoughts?More generally, I'm somewhat surprised that nogc does not still allow allocating Errors (including with assert), as who cares if your program may slightly pause when it's about to crash in a theoretically unrecoverable way.
Jul 12 2014
On 7/10/2014 7:31 PM, Manu via Digitalmars-d wrote:So, we allow assert() in nothrow functions, the argument is that assert is non-recoverable, so it's distinct from user exceptions. I have this in my 'nothrow nogc' function: assert(false, "Message " ~ details); It complains "Error: cannot use operator ~ in nogc function" I think it should be allowed to invoke the GC for formatting error messages inside of assert statements, just the same as assert() is allowed inside of nothrow functions. Thoughts?I've thought of allowing "throw new ...", and yours would be in addition to that, in nogc functions, but was waiting to see how this would play out a bit first.
Jul 10 2014
On Friday, 11 July 2014 at 03:45:17 UTC, Walter Bright wrote:I've thought of allowing "throw new ...", and yours would be in addition to that, in nogc functions, but was waiting to see how this would play out a bit first.Errors I agree with (basically, that's the end of your program, so "violating" nogc is irrelevant in that case). "throw new ..." being allowed in general feels to me like it'll break the entire point of ` nogc` code for many people. ` nogc` was (or, at least I thought it was) designed to stop having people from having to read through implementations of everything their using to verify nothing is using the gc, which was error prone and time consuming. Allowing parts of libraries to throw/get caught somewhere inside of ` nogc` code makes it so you have to go back to manually verifying their not using exception handling somewhere. Sure, it reduces the potential footprint of such, but we're right back to the same old problem again that ` nogc` was supposed to solve. So for people saying "Oh, I want to avoid the GC in D", they'll just complain about how ` nogc` still allows you to hit the GC unintentionally once they find out. Then we'll have requests for ` reallynogc` to be added. Though, again, I'd be ok with if the thing being newed deriving from Error (if it's being thrown immediately). Theoretically I'd also be OK if the `new` throw could be statically verified to be "caught" outside of ` nogc` code (that is, throwing will throw you outside of ` nogc` code, thereby not technically violating ` nogc`). This sort of reasoning is consistent with Errors being allowed to be newed. However, I think that sort of thing is unlikely to be possible.
Jul 10 2014
On Friday, 11 July 2014 at 04:00:05 UTC, Chris Cain wrote:On Friday, 11 July 2014 at 03:45:17 UTC, Walter Bright wrote:I somewhat remember discussion about this originally during the nogc discussions. My stance remains that if you're throwing exceptions, you don't care about the semi-realtime requirements that nogc benefits. Ideally it would be some sort of ref-counted exception, but honestly I think GC exceptions are perfectly okay. If you're concerned whether something might allocate through throwing, you could use nothrow. I get that allowing allocating for throwing exceptions feels 'dirty', but in practice I'd much prefer being able to throw in the extremely rare situation than not be able to mark the method nogc without ugly workarounds. Indeed, the latter would probably bring more allocations than the former.I've thought of allowing "throw new ...", and yours would be in addition to that, in nogc functions, but was waiting to see how this would play out a bit first.Errors I agree with (basically, that's the end of your program, so "violating" nogc is irrelevant in that case). "throw new ..." being allowed in general feels to me like it'll break the entire point of ` nogc` code for many people. ` nogc` was (or, at least I thought it was) designed to stop having people from having to read through implementations of everything their using to verify nothing is using the gc, which was error prone and time consuming. Allowing parts of libraries to throw/get caught somewhere inside of ` nogc` code makes it so you have to go back to manually verifying their not using exception handling somewhere. Sure, it reduces the potential footprint of such, but we're right back to the same old problem again that ` nogc` was supposed to solve. So for people saying "Oh, I want to avoid the GC in D", they'll just complain about how ` nogc` still allows you to hit the GC unintentionally once they find out. Then we'll have requests for ` reallynogc` to be added. Though, again, I'd be ok with if the thing being newed deriving from Error (if it's being thrown immediately). Theoretically I'd also be OK if the `new` throw could be statically verified to be "caught" outside of ` nogc` code (that is, throwing will throw you outside of ` nogc` code, thereby not technically violating ` nogc`). This sort of reasoning is consistent with Errors being allowed to be newed. However, I think that sort of thing is unlikely to be possible.
Jul 10 2014
I've run into my own series of trials and tribulations with a nogc main function (i.e. entire project is nogc). While the idea and implementation is great, its interaction with druntime/Phobos is lacking. This isn't a complete list - it's only what I remember and can reproduce now: 1. destroy(Object) seems to not call the dtor; I'm not sure this is an issue with 2.066 or nogc, seeing as it happens in 2.065 as well: http://dpaste.dzfl.pl/d0c754bb78c6 - to get around this, I wrote my own destroy that automatically calls __dtor. 2. std.typecons.RefCounted doesn't compile in nogc as the dtor isn't nogc. Attempted to annotate it with nogc, but then this happened: Error: nogc function 'std.typecons.RefCounted!(Test, cast(RefCountedAutoInitialize)1).RefCounted.~this' cannot call non- nogc function 'object.destroy!(Test).destroy'. Also attempts to call GC.removeRange, which fails for obvious reasons. Got around this by writing my own ref-counted pointer that uses the destroy replacement from (1). 3. std.container.Array doesn't compile in nogc as it uses std.typecons.RefCounted. Got around this by writing my own Array type. 4. nogc code takes on some of the characteristics of nothrow as Phobos/druntime liberally use `throw new Exception` and `enforce`. This leads to a _vast_ majority of the standard library being locked out. This is really one of the killer issues, and it can only be resolved with allowing GC allocations in failure situations (as Walter says) or by pre-allocating exceptions in the stdlib (which is unlikely). Out of curiosity, as I haven't looked at this problem, what does D do differently to C++ that requires heap allocation of exceptions? 5. As a result of (4), even some of the most trivial things don't work. std.stdio.writeln() (i.e. no arguments) fails because of this: enforce(fputc('\n', .stdout._p.handle) == '\n'); There is _no need_ to enforce that \n was actually output! This is absolutely ridiculous! I got around this by writing my own wrapper around printf that doesn't allocate or throw. 6. std.allocator doesn't work with nogc. Understandable, since it hasn't been updated for nogc yet. Got around this by starting work on my own allocators. 7. This is more a tangential issue, but still a mild irritant: placing nogc at a top of a file doesn't cover the entire module - structs and classes also have to be manually tagged nogc: module test; nogc: struct Test { nogc: this() { /* ... */ } } I ran into these issues with GIT HEAD from 2-3 weeks ago. When I resume work on my nogc project, I'll update to the 2.066 beta/release and report on any more issues. I'm aware that it's early days yet for nogc, so I'm not fussed about these issues, but they are rather concerning. I considered sending in PRs to resolve some of these problems, but fixing the Exception situation (which many of the above stem from) requires significant work.
Jul 10 2014
On 7/10/14, 10:07 PM, Philpax wrote:I've run into my own series of trials and tribulations with a nogc main function (i.e. entire project is nogc). While the idea and implementation is great, its interaction with druntime/Phobos is lacking. This isn't a complete list - it's only what I remember and can reproduce now:[snip] Please paste into one or more bug reports. Thanks! -- Andrei
Jul 10 2014
On Friday, 11 July 2014 at 06:41:56 UTC, Andrei Alexandrescu wrote:On 7/10/14, 10:07 PM, Philpax wrote:Will do once I get back to work on that project and come up with test cases.I've run into my own series of trials and tribulations with a nogc main function (i.e. entire project is nogc). While the idea and implementation is great, its interaction with druntime/Phobos is lacking. This isn't a complete list - it's only what I remember and can reproduce now:[snip] Please paste into one or more bug reports. Thanks! -- Andrei
Jul 11 2014
On Friday, 11 July 2014 at 04:23:20 UTC, Kapps wrote:I somewhat remember discussion about this originally during the nogc discussions. My stance remains that if you're throwing exceptions, you don't care about the semi-realtime requirements that nogc benefits. Ideally it would be some sort of ref-counted exception, but honestly I think GC exceptions are perfectly okay. If you're concerned whether something might allocate through throwing, you could use nothrow. I get that allowing allocating for throwing exceptions feels 'dirty', but in practice I'd much prefer being able to throw in the extremely rare situation than not be able to mark the method nogc without ugly workarounds. Indeed, the latter would probably bring more allocations than the former.Frankly, if there were absolutely no possibilities of workaround, I could accept it. But there's certainly many ways to accomplish this stuff without the GC and it makes it so that you can have a more useful ` nogc` that covers more use cases (specifically, the use cases of the people phobic of the GC). I'll 100% guarantee right now that negative reddit discussions will talk about how ` nogc` doesn't really make sure you don't use the GC if we end up allowing this. I know it's the "easy" solution, but often the "easy" solution won't be the best solution. Plus there's a *huge* difference between the <1 ms of pause on a SINGLE thread that exception handling will incur vs the 3-30ms pause on ALL threads that a GC allocation can cause. Just because exception handling is pretty expensive in terms of regular function calls and such doesn't mean it's completely acceptable to give up all reasonable levels of performance. It's not black-and-white for most use-cases. Not to mention some people want threads that don't even have GC turned on at all. We'll still need a ` reallynogc` for that unless we just want to make it impossible to trust using D libraries for that work (again, throwing away all code/manually hand-verifying code just because some code isn't applicable for working without GC is far too extreme).
Jul 10 2014
On Fri, Jul 11, 2014 at 04:00:01AM +0000, Chris Cain via Digitalmars-d wrote:On Friday, 11 July 2014 at 03:45:17 UTC, Walter Bright wrote:Wouldn't reallynogc == nogc + nothrow ? T -- The only difference between male factor and malefactor is just a little emptiness inside.I've thought of allowing "throw new ...", and yours would be in addition to that, in nogc functions, but was waiting to see how this would play out a bit first.Errors I agree with (basically, that's the end of your program, so "violating" nogc is irrelevant in that case). "throw new ..." being allowed in general feels to me like it'll break the entire point of ` nogc` code for many people. ` nogc` was (or, at least I thought it was) designed to stop having people from having to read through implementations of everything their using to verify nothing is using the gc, which was error prone and time consuming. Allowing parts of libraries to throw/get caught somewhere inside of ` nogc` code makes it so you have to go back to manually verifying their not using exception handling somewhere. Sure, it reduces the potential footprint of such, but we're right back to the same old problem again that ` nogc` was supposed to solve. So for people saying "Oh, I want to avoid the GC in D", they'll just complain about how ` nogc` still allows you to hit the GC unintentionally once they find out. Then we'll have requests for ` reallynogc` to be added.
Jul 11 2014
On Friday, 11 July 2014 at 14:18:35 UTC, H. S. Teoh via Digitalmars-d wrote:Wouldn't reallynogc == nogc + nothrow ?Not precisely. Throwing is perfectly fine in reallynogc. You just can't cheat by allowing allocating exceptions using the GC. Technically it *could* work, but removing exception handling is a bit of a drastic an excessive measure and would make the reallynogc subset pretty weak, especially since basically no libraries are going to work at that point.
Jul 11 2014
On Fri, Jul 11, 2014 at 08:10:21PM +0000, Chris Cain via Digitalmars-d wrote:On Friday, 11 July 2014 at 14:18:35 UTC, H. S. Teoh via Digitalmars-d wrote:Good point. I retract what I said. I think allowing GC operations when throwing Error's is OK, but allowing Exceptions will open up all sorts of issues. It basically allows you to cheat nogc by throwing and catching exceptions within a library call, which defeats the purpose of nogc (why am I getting GC pauses mid-frame when I explicitly said nogc?! Wait, why this library call allocating memory even though it's nogc?! What do you mean it's throwing exceptions under the hood?!). I think allowing GC inside nogc throw is bad. If you really mean business about nogc, you should be preallocating your exceptions and avoiding 'new'. T -- Customer support: the art of getting your clients to pay for your own incompetence.Wouldn't reallynogc == nogc + nothrow ?Not precisely. Throwing is perfectly fine in reallynogc. You just can't cheat by allowing allocating exceptions using the GC. Technically it *could* work, but removing exception handling is a bit of a drastic an excessive measure and would make the reallynogc subset pretty weak, especially since basically no libraries are going to work at that point.
Jul 11 2014
On 11 July 2014 13:45, Walter Bright via Digitalmars-d <digitalmars-d puremagic.com> wrote:On 7/10/2014 7:31 PM, Manu via Digitalmars-d wrote:Well upon updating to 2.066b, the first thing I did was to spam nogc everywhere and see how that worked out, and realised that virtually everywhere I tried was blocked by my assert statements. So I think it's safe to say this needs to be addressed for nogc to be useful.So, we allow assert() in nothrow functions, the argument is that assert is non-recoverable, so it's distinct from user exceptions. I have this in my 'nothrow nogc' function: assert(false, "Message " ~ details); It complains "Error: cannot use operator ~ in nogc function" I think it should be allowed to invoke the GC for formatting error messages inside of assert statements, just the same as assert() is allowed inside of nothrow functions. Thoughts?I've thought of allowing "throw new ...", and yours would be in addition to that, in nogc functions, but was waiting to see how this would play out a bit first.
Jul 10 2014
On 11 July 2014 13:45, Walter Bright via Digitalmars-d <digitalmars-d puremagic.com> wrote:On 7/10/2014 7:31 PM, Manu via Digitalmars-d wrote:I should add, I'm not sure I see that my case should be 'in addition'. I think my case should precede since I don't think it's objectionable, but I'm really unsure I would get on board with 'throw new ...' in nogc functions. It seems to defeat the purpose to me...? Why would you want to allow throwing 'new' exceptions?So, we allow assert() in nothrow functions, the argument is that assert is non-recoverable, so it's distinct from user exceptions. I have this in my 'nothrow nogc' function: assert(false, "Message " ~ details); It complains "Error: cannot use operator ~ in nogc function" I think it should be allowed to invoke the GC for formatting error messages inside of assert statements, just the same as assert() is allowed inside of nothrow functions. Thoughts?I've thought of allowing "throw new ...", and yours would be in addition to that, in nogc functions, but was waiting to see how this would play out a bit first.
Jul 10 2014
On Friday, 11 July 2014 at 05:41:50 UTC, Manu via Digitalmars-d wrote:On 11 July 2014 13:45, Walter Bright via Digitalmars-d <digitalmars-d puremagic.com> wrote:I also have misgivings about this - while it's the easiest solution (as I noted in my previous post), it's also antithetical to nogc. If one rips out the GC entirely, these exceptions end up leaking memory which is arguably an even bigger problem, especially on memory-constrained platforms.On 7/10/2014 7:31 PM, Manu via Digitalmars-d wrote:I should add, I'm not sure I see that my case should be 'in addition'. I think my case should precede since I don't think it's objectionable, but I'm really unsure I would get on board with 'throw new ...' in nogc functions. It seems to defeat the purpose to me...? Why would you want to allow throwing 'new' exceptions?So, we allow assert() in nothrow functions, the argument is that assert is non-recoverable, so it's distinct from user exceptions. I have this in my 'nothrow nogc' function: assert(false, "Message " ~ details); It complains "Error: cannot use operator ~ in nogc function" I think it should be allowed to invoke the GC for formatting error messages inside of assert statements, just the same as assert() is allowed inside of nothrow functions. Thoughts?I've thought of allowing "throw new ...", and yours would be in addition to that, in nogc functions, but was waiting to see how this would play out a bit first.
Jul 10 2014
On 7/10/14, 10:45 PM, Philpax wrote:I also have misgivings about this - while it's the easiest solution (as I noted in my previous post), it's also antithetical to nogc. If one rips out the GC entirely, these exceptions end up leaking memory which is arguably an even bigger problem, especially on memory-constrained platforms.Yah, I'd be hoping that nogc guarantees you can actually not link the gc. -- Andrei
Jul 10 2014
On Friday, 11 July 2014 at 05:41:50 UTC, Manu via Digitalmars-d wrote:Would be great to be able to speficify a custom allocator to exceptions thrown, or at least have it malloc somehow.I've thought of allowing "throw new ...", and yours would be in addition to that, in nogc functions, but was waiting to see how this would play out a bit first.I should add, I'm not sure I see that my case should be 'in addition'. I think my case should precede since I don't think it's objectionable, but I'm really unsure I would get on board with 'throw new ...' in nogc functions. It seems to defeat the purpose to me...? Why would you want to allow throwing 'new' exceptions?
Jul 11 2014
Walter Bright:I've thought of allowing "throw new ...", and yours would be in addition to that, in nogc functions, but was waiting to see how this would play out a bit first.It's true that currently significant parts of Phobos can't be nogc, but the solution is not to turn nogc into its opposite. See: https://d.puremagic.com/issues/show_bug.cgi?id=12768 With a comment by monarchdodra:Bye, bearophilestatic err = new immutable(RangeError)();I'm surprised this works. If the exception is Immutable, then how can we chain it? If we catch "Exception", then we are making something immutable mutable. If we mutate the exception, then not only do we break the type system, but it also means the code isn't actually pure: //---- void foo() pure { static err = new immutable(RangeError)("error"); throw err; } void main() { try foo(); catch(Error e) { e.msg = "yo!"; } foo(); //core.exception.RangeError main.d(7): yo! }
Jul 11 2014
On Friday, 11 July 2014 at 03:45:17 UTC, Walter Bright wrote:I've thought of allowing "throw new ...", and yours would be in addition to that, in nogc functions, but was waiting to see how this would play out a bit first.One can replace throwing of Error with printf + abort in nogc blocks, similar to how assert(false) is reduced to HLT in release builds. Spec allows it. Throwing exceptions should still result in compile-time error though, it is one of primary use cases of nogc.
Jul 11 2014
On Friday, 11 July 2014 at 09:29:58 UTC, Dicebot wrote:On Friday, 11 July 2014 at 03:45:17 UTC, Walter Bright wrote:*throwing _new_ exceptionsI've thought of allowing "throw new ...", and yours would be in addition to that, in nogc functions, but was waiting to see how this would play out a bit first.One can replace throwing of Error with printf + abort in nogc blocks, similar to how assert(false) is reduced to HLT in release builds. Spec allows it. Throwing exceptions should still result in compile-time error though, it is one of primary use cases of nogc.
Jul 11 2014
On Friday, 11 July 2014 at 02:32:00 UTC, Manu via Digitalmars-d wrote:I have this in my 'nothrow nogc' function: assert(false, "Message " ~ details); It complains "Error: cannot use operator ~ in nogc function"I've habitually used 'format' to prepare assert messages with variable content, which has a similar problem -- IIRC it conflicts with nothrow and I guess it too would conflict with nogc.
Jul 11 2014
Joseph Rushton Wakeling:I've habitually used 'format' to prepare assert messages with variable content, which has a similar problem -- IIRC it conflicts with nothrow and I guess it too would conflict with nogc.A solution is to add to Phobos a way to format to an output range, where the range you use a stack-allocated array of chars large enough to contain your formatted message. So on the whole it can be nogc. Bye, bearophile
Jul 11 2014
On Friday, 11 July 2014 at 07:45:24 UTC, bearophile wrote:Joseph Rushton Wakeling:Although I think that is certainly something that would be helpful/necessary, it wouldn't solve the problem of printing out assert messages/exception messages. Basically, the only way I could think to do it is to make a special `NoGCException` that has a `detailMsg` function (taking a `sink`, of course) and your subclass of `NoGCException` would store all the info necessary to print out the error at the catch site and you'd just overload `detailMsg` to print it out properly. https://gist.github.com/Zshazz/47ed52c3246e5348062a That's an example. I store info at line 84 as a tuple in my `SpecialNoGCException`, and set the storage when I'm about to throw at line 202. My apologies for the poor code (I made that stuff as an experiment). It works, but pre-allocating the initial exception is still problematic, IMO. I'd really like a way of specifying that an exception was malloc'd and it's the catcher's job to free it. Obviously, I could "just do it" but it seems pretty unsafe and error-prone. *shrug*I've habitually used 'format' to prepare assert messages with variable content, which has a similar problem -- IIRC it conflicts with nothrow and I guess it too would conflict with nogc.A solution is to add to Phobos a way to format to an output range, where the range you use a stack-allocated array of chars large enough to contain your formatted message. So on the whole it can be nogc. Bye, bearophile
Jul 11 2014
On Friday, 11 July 2014 at 07:45:24 UTC, bearophile wrote:range, where the range you use a stack-allocated array of charsActually, thinking about this more, it's possible if the array of chars is malloc'd instead and written to (of course, that's not ` noalloc`, but that's ok). It's just stack-allocated this way isn't possible since the exception can be thrown into a scope above your stack allocated chars.
Jul 11 2014
A solution is to add to Phobos a way to format to an output range, where the range you use a stack-allocated array of chars large enough to contain your formatted message. So on the whole it can be nogc.That function exists already, it just needs to become nogc, I even filed a ER on this: https://d.puremagic.com/issues/show_bug.cgi?id=13055 Bye, bearophile
Jul 11 2014