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