On Monday, April 03, 2017 15:20:23 Walter Bright via Digitalmars-d wrote: > On 4/3/2017 2:31 PM, Jonathan M Davis via Digitalmars-d wrote: > > Yeah, the simple fact that you can't allocate exceptions in @nogc code > > is > > crippling to @nogc, and a lot of code that could otherwise be @nogc > > can't be because of exceptions - though the exception message poses a > > similar problem (especially if you'd normally construct it with > > format), and I don't know how you get around that other than not using > > anything more informative than string literals. Unless I missed > > something, this proposal seems to ignore that particular issue. > > You're right that this proposal does not address how memory is allocated > for anything indirectly referenced by the exception object. That is an > independent issue, and is not peculiar to exception objects.
No, it's not a problem that's specific to exceptions, but the string for an exception message is pretty critical and is going to have a significant impact on the ability to use @nogc with exceptions. Just being able to have the exception itself be allocated and managed safely via @nogc is definitely a step up, but if we don't have a reasonable way to manage the exception's message in @nogc code, then in many cases, we have a serious problem with how informative exceptions are. And if you really don't care about the exception message saying anything more than you can put in a string literal, you can always pre-allocate the excetion and avoid the whole @nogc problem that way without any of the proposed language changes. As such, I'm inclined to think that the benefits of the proposed changes are minimal if they don't fix the problem with the exception's message being GC-allocated. - Jonathan M Davis
