Jump to page: 1 2
Thread overview
[Issue 16201] When all paths inside a static if return/throw, the portion after static if should be as if "else" were used
Jun 24, 2016
Mathias Lang
Jun 24, 2016
Mathias Lang
Aug 04, 2016
Les De Ridder
Dec 17, 2022
Iain Buclaw
June 24, 2016
https://issues.dlang.org/show_bug.cgi?id=16201

Mathias Lang <mathias.lang@sociomantic.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mathias.lang@sociomantic.co
                   |                            |m

--- Comment #1 from Mathias Lang <mathias.lang@sociomantic.com> ---
I suppose this proposal only applies to function body, and not other places where `static if` might appear ?

--
June 24, 2016
https://issues.dlang.org/show_bug.cgi?id=16201

--- Comment #2 from Andrei Alexandrescu <andrei@erdani.com> ---
(In reply to Mathias Lang from comment #1)
> I suppose this proposal only applies to function body, and not other places where `static if` might appear ?

Correct, sorry for being unclear.

--
June 24, 2016
https://issues.dlang.org/show_bug.cgi?id=16201

Steven Schveighoffer <schveiguy@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |schveiguy@yahoo.com

--- Comment #3 from Steven Schveighoffer <schveiguy@yahoo.com> ---
I think this is a dup of issue 14835.

--
June 24, 2016
https://issues.dlang.org/show_bug.cgi?id=16201

--- Comment #4 from Andrei Alexandrescu <andrei@erdani.com> ---
Sorry for being unclear. It's a superset, not a dupe of 14835. Consider:

void fun(T)(T obj)
{
    static if (!hasMember(T, "gun")) throw new Exception("No gun");
    obj.gun;
}

This code should just work.

--
June 24, 2016
https://issues.dlang.org/show_bug.cgi?id=16201

--- Comment #5 from Steven Schveighoffer <schveiguy@yahoo.com> ---
Thanks for the example. That makes things much clearer.

Essentially, the else code should parse as valid D, but doesn't need to be semantically analyzed once it's determined that the branch will never execute (or at least the error is gagged once it's determined).

--
June 24, 2016
https://issues.dlang.org/show_bug.cgi?id=16201

Steven Schveighoffer <schveiguy@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://issues.dlang.org/sh
                   |                            |ow_bug.cgi?id=14835

--
June 24, 2016
https://issues.dlang.org/show_bug.cgi?id=16201

--- Comment #6 from Mathias Lang <mathias.lang@sociomantic.com> ---
Should it only work on `static if` level ?

E.g. if you have:

```
void fun(T)(T obj)
{
    throw new Exception("No gun");
    obj.gun;
}
```

Should it have the same behaviour ?
If not, that should be fixable at the same time as issue 14835 (and has the
same prerequisites).

However, it's not trivial to implement either, e.g. consider the following code:

```
void fun(T)(T obj)
{
    static if (!hasMember(T, "gun")) {
      if (bar)
         goto Label;
      throw new Exception("No gun");
    }
    // This would not be compiled in after the change, resulting in an
    // "undefined label 'Label'" error.
    Label: myFunc();
}
```

--
June 24, 2016
https://issues.dlang.org/show_bug.cgi?id=16201

--- Comment #7 from Steven Schveighoffer <schveiguy@yahoo.com> ---
One thing that comes to mind on this -- successful compilation will DEPEND on the ability to determine whether a branch escapes or not.

The goto is one thing.

What about a function that always throws and is inlined? (brought up by ketmar in the forum discussion). A clever enough compiler can compile stuff that other compilers do not. In essence the language needs to be very clear to what level the implementation must go in order to prove it shouldn't look at the other pieces.

With the unreachable statement warning, it's just a warning. One can still compile without making it an error (and the warning is optional of course). For this, it's not possible to make it a warning -- the code that should be ignored won't compile.

--
August 04, 2016
https://issues.dlang.org/show_bug.cgi?id=16201

Les De Ridder <dlang@lesderid.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dlang@lesderid.net

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

Iain Buclaw <ibuclaw@gdcproject.org> changed:

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

--
« First   ‹ Prev
1 2