On 4 August 2015 at 00:54, Walter Bright via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On 8/3/2015 8:50 AM, Steven Schveighoffer wrote:
>
>> 1. They aren't removed, they are replaced with a nearly useless segfault.
>>
>
> Not useless at all:
>
> 1. The program does not continue running after it has failed. (Please,
> let's not restart that debate.
> 2. Running it under a debugger, the location of the fault will be
> identified.
>
>
> 2. If we are going to put something in there instead of "assert", why not
>> just
>> throw an error?
>>
>
> Because they are expensive.
>
> To keep asserts in all their glory in released code, do not use the -release switch.
>
>
I think as a guideline, there are really only be two places where using an assert makes sense in druntime/phobos.

1. Internal modules, such as rt and core.internal.
2. Inside contracts (in, out, invariant) or unittests.


Everywhere else - *especially* if it's part of a public API like core.time - you should throw an Exception or Error based on what you see fit.

Because of this view, I'm not really in agreement with the addition of a core.abort module.

Regards
Iain

On Wednesday, 5 August 2015 at 10:31:40 UTC, Iain Buclaw wrote:
> I think as a guideline, there are really only be two places where using an assert makes sense in druntime/phobos.
>
> 1. Internal modules, such as rt and core.internal.
> 2. Inside contracts (in, out, invariant) or unittests.
>
>
> Everywhere else - *especially* if it's part of a public API like core.time - you should throw an Exception or Error based on what you see fit.

I think that it makes perfect sense to use assertions inside of druntime or Phobos functions when testing the correctness of their internal state, but it obviously can't be expected that they run normally (at least in non-templated code), and it can't be expected that much beyond the unit tests run them (at least in non-templated code), since almost no one is going to be using a debug version of druntime/Phobos. Certainly, I don't see anything special about druntime or Phobos with regards to assertions except for the fact that not much beyond the unit tests is going to be using druntime/Phobos in debug mode, so assertions in non-templated code simply aren't going to be doing anything outside of the unit test builds.

As for assert(0) specifically, it makes sense in cases where the code should never ever hit that point, and there's a serious problem if it does (e.g. the default branch of a switch statement where it should be impossible for that branch to be hit), but it was a mistake to use it in core.time, since that was failing based on a system call returning a failure (which should basically never happen in this case, but it still depends on the environment and thus could conceivably fail as opposed to only ever failing if druntime's code is definitely broken).

> Because of this view, I'm not really in agreement with the addition of a core.abort module.

Well, then please comment on the PR: https://github.com/D-Programming-Language/druntime/pull/1337

It seems to me that the whole point of abort is to work around the fact that Walter doesn't want assert(0) to print messages before the HLT instruction in release mode. Certainly, I can't see any other reason for it.

- Jonathan M Davis

On 8/5/15 12:46 PM, Jonathan M Davis wrote:
> Well, then please comment on the PR:
> https://github.com/D-Programming-Language/druntime/pull/1337
>
> It seems to me that the whole point of abort is to work around the fact
> that Walter doesn't want assert(0) to print messages before the HLT
> instruction in release mode. Certainly, I can't see any other reason for
> it.

No, the reason is, if you want to print something before halting, and you don't want to use any subsystems that you suspect are corrupt (e.g. stdio), it's not a simple task. This makes it as simple as calling assert. I thought it would be a useful utility.

Surely, we can improve core.time to throw in this case instead, since the case where the ticksPerSecond is zero only happens when the OS did not provide it. A slight possibility is that the memory was corrupted.

But I think the abort function still has use in other cases.

-Steve