Add an "assert" function

[carlosgalvezp]

Hi,

There is already a fail function, but it's not ergonomic to use, because it takes 2 lines and 1 added indentation level. It would be good if we could have a assert function. Consider:

if (not condition):
   fail("Error message")

vs

assert(condition, "Error message")

The same code with assert is much cleaner. It's also consistent with most programming languages.

[laurentlb]

In Python 3, this line is a no op:

>>> assert(False, "abc")
<stdin>:1: SyntaxWarning: assertion is always true, perhaps remove parentheses?

The syntax is actually without parentheses:

assert someExpression
assert someExpression, "error message"

So the request would require a change in the syntax (and all Starlark-aware tooling).

We would also need a way to prevent users from writing the no-op line assert(False, "abc"), as it's very error-prone.

[fenollp]

As someone that ported pytruth to Starlark (see google/starlark-go#361) I'd like the assert statement to be correctly parsed so that I'd be able to bind its behavior in this way:

assert that("this").is_not_equal_to("that")

Today I'm able to declare assert as a module and that as its only method. I very awkwardly s/assert that/assert.that/g for the syntax support... so I support its addition to the spec!

[carlosgalvezp]

So the request would require a change in the syntax (and all Starlark-aware tooling).

I don't quite know the requirements of Starlark - is it a requirement that it must be Python3 - compatible? Creating an assert() function would be trivial if we didn't need to support the same Python3 syntax.

[brandjon]

We try to be at least syntactically a subset of Python 3, and not differ semantically more than necessary.

Right now, assert is banned as a token in the language spec and at least the Java implementation. If we're going to add it, we'd probably want to do so in a way that is syntactically still compatible with Python, although we could be more demanding than Python by requiring the parentheses.

I'm not sure the benefit of condensing two lines down to one is enough to justify introducing a new builtin that serves basically the same purpose as fail().

FWIW, the test suite for the Java implementation defines assert_eq() and assert_() helper functions (natively in Java code, though you could also write them trivially in Starlark in terms of fail()).

[carlosgalvezp]

Understood, I agree that one can trivially create such a function on their own and saving 1 line of code might not outweigh the implications mentioned here. Closing the issue, thank you!