Guarantee @assert will not be removed

[jariji]

Several people have suggested that @assert should never be removed because too many people rely on it for correctness. This PR changes the docstring to guarantee that it will not be removed.

This PR is an alternative to @check from #41342.

[jariji]

In many languages assert p means "removable assertion", whereas here it means "unremovable assertion". That's not ideal.

I do still want a way to put function-internal debug assertions that get removed for releases. On Slack @adienes suggested @assert :debug p for the debug-mode-only assertion.

[jariji]

I'm hoping to get a "guaranteed never-removed check" into 1.11 - I don't care so much if it's called @assert or @check.

@DilumAluthge I see from the other PR that you favor @check.

@vchuravy I see your 👎, would you mind explaining your position regarding @assert/@check?

[vtjnash]

I think some languages also call the removable checks preconditions (or postconditions)?

[Seelengrab]

I think some languages also call the removable checks preconditions (or postconditions)?

Do you have an example of that? Such an interpretation would invert the meaning of "precondition", i.e. a condition that is assumed to be true to make that call sound. The check isn't really removed, but assumed to be done/inferred ahead of time.

[vtjnash]

Swift calls them preconditions at times https://developer.apple.com/documentation/swift/precondition(_:_:file:line:)#discussion (though it also has assertions)
I think ADA also does (http://www.ada-auth.org/standards/12aarm/html/AA-6-1-1.html) as a subclass of the assertion configuration options https://docs.adacore.com/live/wave/arm05/html/arm05/RM-11-4-2.html

[BioTurboNick]

For a while .Net had "Code Contracts" with preconditions, invariants, and postconditions, but it has been abandoned: https://learn.microsoft.com/en-us/dotnet/framework/debug-trace-profile/code-contracts

They were conditionally compiled -- removed by default.

FWIW, .Net has separate "Debug.Assert" and "Trace.Assert" methods, the former is removed in release and the latter is retained. (based on a compiler symbol that is defined by default, so it's still technically removable if someone wanted.)

[Seelengrab]

Use this function to detect conditions that must prevent the program from proceeding, even in shipping code.

Swift doesn't remove them though:

Use this function to detect conditions that must prevent the program from proceeding, even in shipping code.

It only removes the check with -Ounchecked, where the condition is assumed to be checked elsewhere (otherwise it's unsound).

I'm not sure I understand the ADA docs correctly, but I think the "enabled" there refers to whether its required to be checked by some other part of the class hierarchy..?

--

Either way, I think it's good to have non-removable version in general, but I don't think @assert should be that. It already has a long documented meaning; changing that now seems odd.

[ericphanson]

If we want to call it something else we should do #41342; if not, we should do this. But I think we should do one of them.

[fingolfin]

In all languages I am familiar with, assertion checks are for debugging, and can be disabled in "release builds". They are in particular not meant for user input validation, but rather for checking internal state where a diversion from the expect is really indicator of some fundamental issue.

So my preference is that Julia follow this pattern. We define our own macros for use in argument validation (which throw ArgumentError) and a few other things; of course it'd be nice if there was something in Julia itself so that people don't have to reinvent the wheel. But I don't see why having such a macro should a precondition for deciding the future of @assert .

[inkydragon]

It already has a long documented meaning; changing that now seems odd.

The documentation mentions not relying on @assert checks.
Would this pr be a breaking change?

[jariji]

No this is not breaking, it only adds guarantees.

[fingolfin]

Someone needs to make a decision on this one...

[Seelengrab]

I don't think this "needs" a decision per-se; judging by the 👎 on the original post, people seem to be pretty opposed to changing the guarantees of @assert.

[jariji]

The only counterargument made in this thread is consistency with other languages:

In all languages I am familiar with, assertion checks are for debugging, and can be disabled in "release builds".

However, Rust is a counterexample: it distinguishes assert and debug_assert:

Assertions are always checked in both debug and release builds, and cannot be disabled. See debug_assert! for assertions that are not enabled in release builds by default.

I sorta think consistency with Rust is almost as good as consistency with a bunch of other languages. There is another strong argument in favor, which is that a fair amount code already acts as if @assert is nonremovable.

Are there any other arguments against merging?