On 4/3/2017 11:59 PM, Jonathan M Davis via Digitalmars-d wrote:
> 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.

https://github.com/dlang/druntime/blob/master/src/object.d#L1701

On Tuesday, 4 April 2017 at 00:45:08 UTC, Moritz Maxeiner wrote:
> AFAICT this solution will end up with everyone always calling theAllocator.dispose when catching from Phobos.

Yes, because you can no longer assume that the GC is being used, as all current Phobos code does.

Here's the thing, this problem misses the forrest for the trees. Focusing on exceptions is not seeing the broader problem of the user being at the mercy of Phobos devs with their choices of allocations. Exceptions are one aspect of the problem of allocation in a standard library with multiple allocation methods available. It's only as a matter of convenience that we've been using the GC for everything when stack allocation isn't enough. If we want to compete with Rust and C++* need a clean way to let the user control memory throughout their program.

As already pointed out, this is one ad-hoc solution to a specific problem rather than a holistic solution.


* to be honest, I would be fine if it was concluded that this isn't what we want to compete with. Java and C# didn't mostly replace C++ by being "C++ but slightly different". They won because they were something different that allowed you to get shit done. What does D want to be, a better C++ or a better language?

I don't think it's possible to have a clean language + std library and have the same amount of power as C++, the GC is just to convenient and takes off so much cognitive load. If we want to compete with C++ with Phobos, Phobos will need to become more ugly but more flexible.

On Monday, 3 April 2017 at 15:16:31 UTC, Jack Stouffer wrote:
> On Monday, 3 April 2017 at 14:36:43 UTC, Kagamin wrote:
>> I suppose they link-hack GC, not druntime.
>
> Nope, they get rid of everything, see https://theartofmachinery.com/2016/12/18/d_without_runtime.html

That article is pretty careful:
>As an example
>as if it were C code to begin with
>Even then, there are useful compromises between the extremes of “no D runtime” and “full D runtime”.
Also see the next post https://theartofmachinery.com/2017/01/24/boot_to_d.html - not exactly GC purity.
Also the removed parts there are not runtime, but compiler generated stuff added to the object file that would need runtime, like reference to the personality function.

On Tuesday, 4 April 2017 at 08:41:51 UTC, Walter Bright wrote:
> On 4/4/2017 1:08 AM, Atila Neves wrote:
>> I think the point here is that some people already use pre-allocated exceptions.
>> With this proposal, they'd have to change their codebase or suddenly have it go
>> much slower.
>
> High performance code should never have exceptions in the fast path. The code gen is heavily and unapologetically biased towards speed in the non-exception path. This is true for C++ and D.

Right, but that doesn't mean the slow path should become all the more slower for codebases that do this. I haven't, but if I had I'd imagine I'd be none too happy about it.

Atila

On 4/4/2017 10:38 AM, Atila Neves wrote:
> Right, but that doesn't mean the slow path should become all the more slower for
> codebases that do this. I haven't, but if I had I'd imagine I'd be none too
> happy about it.

A year ago or so, I switched the exception unwinding mechanism for D on Linux from our custom solution to the Elf method used by every other language on Linux. It's a lot slower now - but it's compatible :-)

Copying a dozen bytes isn't going to make any measurable difference.

On 04/04/2017 04:08 AM, Atila Neves wrote:
>
> I think the point here is that some people already use pre-allocated
> exceptions. With this proposal, they'd have to change their codebase or
> suddenly have it go much slower.
>

Isn't the main point of pre-allocated exceptions to improve control/determinism in memory usage/allocation?

I don't think speed is the issue. As I see it, the issue is that it takes "this throw was SPECIFICALLY DESIGNED to NOT affect the heap" and turns it into "this throw DOES affect the heap, even though the author went out of their way to deliberately prevent that".

Much of Phobos has been redone to not assume/require the GC. A glaring exception (!) is when Exceptions are thrown, which is why we're looking for a solution.

On Wednesday, 5 April 2017 at 09:51:16 UTC, Walter Bright wrote:
> Much of Phobos has been redone to not assume/require the GC. A glaring exception (!) is when Exceptions are thrown, which is why we're looking for a solution.

Much, but not most. Dynamic arrays, AAs, closures, and all classes are still heavily used in Phobos. More than half of all the modules in Phobos rely on GC.

Again: making throwing exceptions @nogc WILL make a small number of the overall currently allocating functions @nogc. It will NOT make the majority of Phobos @nogc and it doesn't come close to the main problem already stated in my other comments.

You're adding in a confusing special case for a small piece of the overall whole and missing the forrest for the trees.

On Monday, 3 April 2017 at 22:30:46 UTC, Walter Bright wrote:
>
> Using a singleton in TLS is indeed memory safe, as long as you don't do things like keep a reference to it around and expect it not to change.

But those of us with the runtime disabled don't have TLS.
throwing, .destroy, TLS (and static this) are the fragmenting factors between runtime-free and D normal D.

On Wednesday, 5 April 2017 at 14:35:18 UTC, Guillaume Piolat wrote:
> But those of us with the runtime disabled don't have TLS.

This is only true on DMD/OS X x86, where TLS is emulated in druntime. On other platforms, TLS is implemented by the linker and/or C runtime, so it works without druntime just fine.

Regular thread-local module constructors (static this) of course won't work without druntime support, as they are mediated through ModuleInfo.

 — David