www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - nogc

reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
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
next sibling parent reply "Kapps" <opantm2+spam gmail.com> writes:
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
parent reply Piotr Szturman <bncrbme jadamspam.pl> writes:
W dniu 2014-07-11 05:18, Kapps pisze:
 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.
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).
Jul 12 2014
parent "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Saturday, 12 July 2014 at 09:44:16 UTC, Piotr Szturman wrote:
 W dniu 2014-07-11 05:18, Kapps pisze:
 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.
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).
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.
Jul 12 2014
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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
next sibling parent reply "Chris Cain" <zshazz gmail.com> writes:
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
next sibling parent reply "Kapps" <opantm2+spam gmail.com> writes:
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'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.
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.
Jul 10 2014
next sibling parent reply "Philpax" <phillip philliplarkson.com> writes:
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
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
parent "Philpax" <phillip philliplarkson.com> writes:
On Friday, 11 July 2014 at 06:41:56 UTC, Andrei Alexandrescu 
wrote:
 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
Will do once I get back to work on that project and come up with test cases.
Jul 11 2014
prev sibling parent "Chris Cain" <zshazz gmail.com> writes:
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
prev sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
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:
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.
Wouldn't reallynogc == nogc + nothrow ? T -- The only difference between male factor and malefactor is just a little emptiness inside.
Jul 11 2014
parent reply "Chris Cain" <zshazz gmail.com> writes:
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
parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
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:
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.
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.
Jul 11 2014
prev sibling next sibling parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
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:
 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.
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.
Jul 10 2014
prev sibling next sibling parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
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:
 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.
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 10 2014
next sibling parent reply "Philpax" <phillip philliplarkson.com> writes:
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:
 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.
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?
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.
Jul 10 2014
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
prev sibling parent "ponce" <contact gam3sfrommars.fr> writes:
On Friday, 11 July 2014 at 05:41:50 UTC, Manu via Digitalmars-d 
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.
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?
Would be great to be able to speficify a custom allocator to exceptions thrown, or at least have it malloc somehow.
Jul 11 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
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:
         static 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! }
Bye, bearophile
Jul 11 2014
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
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
parent "Dicebot" <public dicebot.lv> writes:
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:
 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.
*throwing _new_ exceptions
Jul 11 2014
prev sibling parent reply "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> writes:
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
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
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
next sibling parent "Chris Cain" <zshazz gmail.com> writes:
On Friday, 11 July 2014 at 07:45:24 UTC, bearophile wrote:
 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
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*
Jul 11 2014
prev sibling next sibling parent "Chris Cain" <zshazz gmail.com> writes:
On Friday, 11 July 2014 at 07:45:24 UTC, bearophile wrote:
 range, where the range you use a stack-allocated array of chars
Actually, 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
prev sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
 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