https://issues.dlang.org/show_bug.cgi?id=14534

Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla@digitalmars.com

--- Comment #1 from Walter Bright <bugzilla@digitalmars.com> ---
I don't think this is an enhancement - it's a bug fix. All the compilers must do the same thing.

--

https://issues.dlang.org/show_bug.cgi?id=14534

yebblies <yebblies@gmail.com> changed:

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

--- Comment #2 from yebblies <yebblies@gmail.com> ---
The way to make this precisely defined is to put it in the spec and test suite, not to move the lowering into the frontend.  Lowering early is not without downsides.

--

https://issues.dlang.org/show_bug.cgi?id=14534

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ibuclaw@gdcproject.org

--- Comment #3 from Iain Buclaw <ibuclaw@gdcproject.org> ---
(In reply to yebblies from comment #2)
> The way to make this precisely defined is to put it in the spec and test suite, not to move the lowering into the frontend.  Lowering early is not without downsides.

In some cases, yes.  But in this instance, I don't think so.

After we've verified condition->toBoolean() the only other time semantic analysis is done on the condition is for optimizations.  And I seriously doubt that we are likely going to get any meaningful constant literal optimized out from any of these types.

--

https://issues.dlang.org/show_bug.cgi?id=14534

--- Comment #4 from yebblies <yebblies@gmail.com> ---
(In reply to Iain Buclaw from comment #3)
> In some cases, yes.  But in this instance, I don't think so.
> 
> After we've verified condition->toBoolean() the only other time semantic analysis is done on the condition is for optimizations.  And I seriously doubt that we are likely going to get any meaningful constant literal optimized out from any of these types.

One example is error messages - I would much rather see

if (dg)

than

if ((auto tmp = dg, tmp.funcptr != null && tmp.ptr != null))

Lowering to

if (cast(bool)dg)

would be acceptable, but the lowering would still be in the backend.  Maybe this is done late enough that it wouldn't affect error messages anyway?

--

https://issues.dlang.org/show_bug.cgi?id=14534

--- Comment #5 from Iain Buclaw <ibuclaw@gdcproject.org> ---
Attempt: https://github.com/D-Programming-Language/dmd/pull/4630

--

https://issues.dlang.org/show_bug.cgi?id=14534

--- Comment #6 from Iain Buclaw <ibuclaw@gdcproject.org> ---
This in particular what really irks me.
---
int test()
{
    int[int] aa = [1:2];
    int[] array = [1,2];

    aa.remove(1);
    array.length = 0;

    if (__ctfe)
        assert(!aa);
    else
        assert(aa);

    if (__ctfe)
        assert(!array);
    else
        assert(array);

    return 1;
}
---

We have a split brain between what CTFE evaluates as true vs. runtime!

--

https://issues.dlang.org/show_bug.cgi?id=14534

Iain Buclaw <ibuclaw@gdcproject.org> changed:

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

--

https://issues.dlang.org/show_bug.cgi?id=14534

--- Comment #7 from dlangBugzillaToGithub <robert.schadek@posteo.de> ---
THIS ISSUE HAS BEEN MOVED TO GITHUB

https://github.com/dlang/dmd/issues/18985

DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB

--