Thread overview
[Issue 14387] Disallow string literals as assert conditions
Apr 02, 2015
Don
Apr 05, 2015
Vladimir Panteleev
Dec 04, 2022
Nick Treleaven
Dec 17, 2022
Iain Buclaw
Nov 20, 2023
Dlang Bot
Nov 24, 2023
Dlang Bot
Dec 29, 2023
Dlang Bot
Jan 26, 2024
Nick Treleaven
April 02, 2015
https://issues.dlang.org/show_bug.cgi?id=14387

--- Comment #1 from Don <clugdbug@yahoo.com.au> ---
The spec says:

"As a debugging tool, the compiler may insert checks to verify that the condition indeed holds by evaluating AssignExpression at runtime. If it evaluates to a non-null class reference, the class invariant is run. Otherwise, if it evaluates to a non-null pointer to a struct, the struct invariant is run. Otherwise, if the result is false, an AssertError is thrown. If the result is true, then no exception is thrown. In this way, if a bug in the code causes the assertion to fail, execution is aborted, prompting the programmer to fix the problem. "

This does not mention the case where the expression evaluates to a string literal.

At the very least this is a bug in the spec. It seems that, if the expression evaluates neither to a class reference, nor to a pointer to a struct, then the expression is implictly converted to bool. But the spec doesn't say that.

IMHO it's also pretty weird that string literals are implicitly convertable to bool. Note that they weren't convertable in D1:  assert("abc"); and if("abc") both generated compile-time errors. I don't think that was an intentional change, but I could be wrong.

--
April 05, 2015
https://issues.dlang.org/show_bug.cgi?id=14387

Vladimir Panteleev <thecybershadow@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |thecybershadow@gmail.com

--- Comment #2 from Vladimir Panteleev <thecybershadow@gmail.com> ---
(In reply to Don from comment #1)
> IMHO it's also pretty weird that string literals are implicitly convertable to bool. Note that they weren't convertable in D1:  assert("abc"); and if("abc") both generated compile-time errors. I don't think that was an intentional change, but I could be wrong.

For non-static assert, D1 and D2 pre 2.023 say:

test.d(4): Error: expression "test" of type invariant(char[4u]) does not have a
boolean value

>From 2.023 changelog:

"the type of a string literal is now invariant(char)[] rather than invariant(char)[length_of_string]. It is still implicitly convertible to the latter. This is intended to reduce template instantiation bloat."

This is a case of dynamic arrays implicitly converting to bool whether they're null or non-null. So, this will automatically be "fixed" when implicit array-to-bool conversion is deprecated ( https://github.com/D-Programming-Language/dmd/pull/2885 ).

--
December 04, 2022
https://issues.dlang.org/show_bug.cgi?id=14387

Nick Treleaven <nick@geany.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nick@geany.org

--- Comment #3 from Nick Treleaven <nick@geany.org> ---
> this will automatically be "fixed" when implicit array-to-bool conversion is deprecated ( https://github.com/D-Programming-Language/dmd/pull/2885 ).

Sadly that was reverted and Issue 4733 was marked as WONTFIX.

--
December 17, 2022
https://issues.dlang.org/show_bug.cgi?id=14387

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P4

--
November 20, 2023
https://issues.dlang.org/show_bug.cgi?id=14387

Dlang Bot <dlang-bot@dlang.rocks> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |pull

--- Comment #4 from Dlang Bot <dlang-bot@dlang.rocks> ---
@ntrel created dlang/dmd pull request #15837 "Deprecate boolean evaluation of array/string literals" fixing this issue:

- Deprecate boolean evaluation of array/string literals

  Fix Issue 14387 - Disallow string literals as assert conditions.

https://github.com/dlang/dmd/pull/15837

--
November 24, 2023
https://issues.dlang.org/show_bug.cgi?id=14387

--- Comment #5 from Dlang Bot <dlang-bot@dlang.rocks> ---
@ntrel created dlang/dmd pull request #15860 "Deprecate string literals as (static) assert conditions" fixing this issue:

- Deprecate string literals as assert conditions

  Fix Issue 14387 - Disallow string literals as assert conditions

https://github.com/dlang/dmd/pull/15860

--
December 29, 2023
https://issues.dlang.org/show_bug.cgi?id=14387

Dlang Bot <dlang-bot@dlang.rocks> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #6 from Dlang Bot <dlang-bot@dlang.rocks> ---
dlang/dmd pull request #15860 "Deprecate string literals as (static) assert conditions" was merged into master:

- 55d0483a5d5ceef59327cde7cb12124d98547459 by Nick Treleaven:
  Deprecate string literals as assert conditions

  Fix Issue 14387 - Disallow string literals as assert conditions

https://github.com/dlang/dmd/pull/15860

--
January 26, 2024
https://issues.dlang.org/show_bug.cgi?id=14387

Nick Treleaven <nick@geany.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |temtaime@gmail.com

--- Comment #7 from Nick Treleaven <nick@geany.org> ---
*** Issue 11080 has been marked as a duplicate of this issue. ***

--