On 12.12.2016 22:35, Brad Roberts via Digitalmars-d wrote:
> On 12/12/16 12:59 PM, Andrei Alexandrescu via Digitalmars-d wrote:
>> On 12/12/2016 11:35 AM, safety0ff wrote:
>>> On Monday, 12 December 2016 at 15:51:07 UTC, Andrei Alexandrescu wrote:
>>>>
>>>> But of course there are many situations out there.
>>>
>>> Wouldn't it break chained assertion errors?
>>
>> Once a type in Error's cone gets thrown there is no guarantee of
>> unwinding, hence no guarantee of
>> chaining. -- Andrei
>
> For this to have much meaning, at some-point druntime (for all the
> various compilers) is going to need to be changed to not unwind.  It
> does, and has all the effects that come from that.  What actually
> happens tends to trump what the documentation claims it's allowed to not
> do.  Of course, then you'll find the fun of all the tests (and probably
> code) that catch AssertError.
>

There is a /language feature/ ('in'-contract inheritance) that relies on normal execution after catching AssertError.

On 12/12/16 4:35 PM, Brad Roberts via Digitalmars-d wrote:
> Of course, then you'll find the fun of all the tests (and probably code)
> that catch AssertError.

You can catch AssertError. There's no guarantees dtors have been called during unwinding. -- Andrei

On Monday, 12 December 2016 at 17:57:13 UTC, Adam D. Ruppe wrote:
> On Monday, 12 December 2016 at 16:35:22 UTC, safety0ff wrote:
>> Wouldn't it break chained assertion errors?
>
> An Error is unrecoverable anyway, if such a case arises it can always just abort the program immediately.

I think all error can be a singleton, and when has the erro, the program should be killed.
But Exception should be new , and in GC. we can use the GC.free to free the memony.

On Tuesday, 13 December 2016 at 03:07:56 UTC, Dsby wrote:
> On Monday, 12 December 2016 at 17:57:13 UTC, Adam D. Ruppe wrote:
>> On Monday, 12 December 2016 at 16:35:22 UTC, safety0ff wrote:
>>> Wouldn't it break chained assertion errors?
>>
>> An Error is unrecoverable anyway, if such a case arises it can always just abort the program immediately.
>
> I think all error can be a singleton, and when has the erro, the program should be killed.
> But Exception should be new , and in GC. we can use the GC.free to free the memony.

Error should not hide and catch. When the erro, the Program should be immediately exited!
If the Erro can catch, will has other error form this erro!

On Monday, 12 December 2016 at 21:02:11 UTC, Andrei Alexandrescu wrote:
> On 12/12/2016 02:54 PM, Shachar Shemesh wrote:
>> Now, if you'd make regular Exceptions GC free....
>
> That will come too.

Then why bother making Errors singletons in order to avoid the GC? The problem you're trying to fix with this singleton suggestion would then be fixed anyway.

- Jonathan M Davis

On Monday, 12 December 2016 at 15:51:07 UTC, Andrei Alexandrescu wrote:
> Here it is:
>
> https://github.com/dlang/druntime/pull/1710
>
> It relieves code that uses assert from needing the GC. I think all Errors should be singletons - multiple objects in that hierarchy arguably make no sense. But of course there are many situations out there. If this breaks your code, please holler.

I don't know if that would actually work with polymorphic contracts in classes. It also could be problematic with unit tests - especially unit tests that catch AssertErrors (e.g. if someone wants to test the contracts).

I also fail to see how this fixes much of anything. If the issue is avoiding the GC, it doesn't matter if the program is being killed. If the issue is avoiding even linking in the GC, doesn't that mean that druntime isn't being used (in which case, doing this in druntime is pointless)? So, I don't see how such a change would matter for either scenario, and I don't know why else it would be of any value.

And if we fix it so that exceptions don't need the GC (which is arguably needed for @nogc to be widely used), then this whole problem goes away anyway. So, I'm inclined to argue that we just fix _that_ problem and not worry about the fact that assert currently triggers the GC on failure.

- Jonathan M Davis

On 12/12/16 11:07 PM, Jonathan M Davis wrote:
> On Monday, 12 December 2016 at 15:51:07 UTC, Andrei Alexandrescu wrote:
>> Here it is:
>>
>> https://github.com/dlang/druntime/pull/1710
>>
>> It relieves code that uses assert from needing the GC. I think all
>> Errors should be singletons - multiple objects in that hierarchy
>> arguably make no sense. But of course there are many situations out
>> there. If this breaks your code, please holler.
>
> I don't know if that would actually work with polymorphic contracts in
> classes.

How do you mean that? Do you have an example in mind?

> It also could be problematic with unit tests - especially unit
> tests that catch AssertErrors (e.g. if someone wants to test the
> contracts).

What kind of problems would it create?

> I also fail to see how this fixes much of anything. If the issue is
> avoiding the GC, it doesn't matter if the program is being killed. If
> the issue is avoiding even linking in the GC, doesn't that mean that
> druntime isn't being used (in which case, doing this in druntime is
> pointless)? So, I don't see how such a change would matter for either
> scenario, and I don't know why else it would be of any value.

Is reducing dependencies for core constructs a good thing?

> And if we fix it so that exceptions don't need the GC (which is arguably
> needed for @nogc to be widely used), then this whole problem goes away
> anyway. So, I'm inclined to argue that we just fix _that_ problem and
> not worry about the fact that assert currently triggers the GC on failure.

I agree the perfect system would fix everything - problem is we don't have it yet. The per-thread singleton is a step forward (which at some point we should probably make publicly available).


Andrei

On 12/12/16 23:02, Andrei Alexandrescu wrote:
> On 12/12/2016 02:54 PM, Shachar Shemesh wrote:
>> On 12/12/16 17:51, Andrei Alexandrescu wrote:
>>> Here it is:
>>>
>>> https://github.com/dlang/druntime/pull/1710
>>>
>>> It relieves code that uses assert from needing the GC. I think all
>>> Errors should be singletons - multiple objects in that hierarchy
>>> arguably make no sense. But of course there are many situations out
>>> there. If this breaks your code, please holler.
>>>
>>>
>>> Andrei
>>
>> As you may know, Weka has a huge GC aversion. Despite that fact, I fail
>> to see the improvement such a change would bring.
>
> Why am I not surprised :o).

I'm not sure what to make of that comment.

>
>> The only situation
>> under which using the GC is not harmful is when the entire process is
>> about to go kaboom anyways.
>
> You get to use assert without needing to link in the GC.
>

int func(int num1, int num2, int num3)
body
{
    int result;
    scope(exit)
            assert(result>20);

    assert(num1>5);
    result += num1;
    assert(num2>10);
    result += num2;
    assert(num3>5);
    result += num3;

    // Some more work

    return result;
}

Yes, I know, there multiple ways in which this function can be written much better, and in all of them the double assert won't happen. Such a case may actually happen, however, particularly if the first assert to happen happens in a sub-function.

What is supposed to happen, after your proposed change, if I call "func(1, 2, 3)"?

Shachar

On 13/12/16 06:45, Andrei Alexandrescu wrote:
> I agree the perfect system would fix everything - problem is we don't
> have it yet. The per-thread singleton is a step forward (which at some
> point we should probably make publicly available).
>
>
> Andrei

If it's not going to be needed once exceptions are GC free, and unlinking GC from phobos is not likely to happen until that happens, can you explain how is it a step forward?

To me, it seems like it isn't heading where we're going and it doesn't provide any extra benefit for the interim time.

Shachar

On 13/12/16 02:57, Andrei Alexandrescu wrote:
>
> You can catch AssertError. There's no guarantees dtors have been called
> during unwinding. -- Andrei

That makes no sense to me, unless you only want to catch it in order to do something right before exiting anyways.

Also, please note that not all non-Exception Throwables are terminal for the process. We use a Throwable that is not an Exception in order to force termination of a fiber from outside in a clean way. If proper unwinding is not guaranteed under this condition, we have a problem.

Shachar