<p>Let's say your designing a new language with syntax and semantics similare to other C-style languages (C#, Java, C++, JS, etc). You want the language to have <code>if</code>-statements.</p>
<p>Does it need support for <code>else</code>-statements? Is there anything you can't do with the early return design pattern?</p>
<p><strong>edit</strong></p>
<p>The question was if you could design a new language without else statements, or if there would be some algoritms in such a language that would be impossible to code. In other words; is else necessary or simply a convenience?</p>

<language-design>
Else-statements
CC BY-SA 4.0
2023-11-05T15:09:54.697Z
`else` is not a kind of statement, it is a part of an `if` statement. There is no language I know of where you can write `else` as a statement by itself. Your question also doesn't say what you mean by "need" ─ need for what purpose? If the goal is only to have "syntax and semantics similar to other C-style languages" then the answer is yes or no depending on what you mean by "similar". It's also unclear what benefit you might expect from a language *not* having `else` clauses.
kaya3
CC BY-SA 4.0
2023-11-05T15:17:39.303Z
While the question is on topic IMO, it is extremely trivial; as @kaya3 said, what benefit is there *not* to have `else`?
Seggan
CC BY-SA 4.0
2023-11-05T15:19:12.347Z
Nonetheless, the answer would be "no", because you can evaluate the predicate into a local variable and then have a second if with a not to mimic the behavior of the else part. However, nobody would do that because it would require extra code and real code would likely have a performance penalty because users would reevaluate predicates.
feldentm
CC BY-SA 4.0
2023-11-05T20:07:08.353Z
@kaya3: In some interpreted languages, an "if" statement doesn't contain other statements, but rather manipulates a combination of state variables which suppresses normal execution of other statements unless/until an "else" or "endif" is executed.
supercat
CC BY-SA 4.0
2023-11-06T11:37:44.990Z
The question was if you could design a new language without `else` statements, or if there would be some algoritms in such a language that would be impossible to code. In other words; is `else` necessary or simply a convenience?
Knarf
CC BY-SA 4.0
2023-11-07T01:36:47.383Z
@Knarf Well as the answer shows a second if with just the same condition inverted could be a substitute for `else` in all cases... but of course that would be slower and more verbose and less readible than just having an `else` statement.
CPlus
CC BY-SA 4.0
2023-11-07T06:09:21.573Z
@Knarf In that case, I think what you want is [Turing-completeness](https://en.wikipedia.org/wiki/Turing_completeness). (In short, it's a convenience.)
user23013
<p>Consider a typical conditional statement.</p>
<pre><code>if (condition) {
    // Do stuff if true
} else {
    // Do stuff if false
}
</code></pre>
<p>In general, you should be able to rewrite this to not use <code>else</code>.</p>
<pre><code>let c = condition;
if (c) {
    // Do stuff if true
}
if (!c) {
    // Do stuff if false
}
</code></pre>
<p>Replacing <code>else</code> with an early return gets a little trickier.</p>
<pre><code>if (some_environment_variable()) {
    os.write_to_file(&quot;The environment variable is true!&quot;)
} else {
    os.write_to_file(&quot;The environment variable is false.&quot;)
}

os.write_to_file(&quot;Both cases considered!&quot;)
</code></pre>
<p>This could be transformed to</p>
<pre><code>fn test_env_var() {
    if (some_environment_variable()) {
        os.write_to_file(&quot;The environment variable is true!&quot;)
        return
    }
    os.write_to_file(&quot;The environment variable is false!&quot;)
    return
}

test_env_var();
os.write_to_file(&quot;Both cases considered!&quot;)
</code></pre>
<p>But just because you <em>can</em> do this does not mean you <em>should</em>. Examples in the real world are not as trivial as these. Imagine being forced to write 10 different functions with early returns instead of a simple if/else chain.</p>

CC BY-SA 4.0
2023-11-05T15:37:50.540Z
2023-11-05T15:37:50.540Z
Luke LaBonte
CC BY-SA 4.0
2023-11-07T22:06:58.587Z
I'm not an adherent, but the proponents of else-less programming would probably disagree with you.
Barmar
<p>The ability to evaluate conditions and have different portions of the following code execute based upon their values is useful, and would be far less useful if the it were not possible to have some code's execution conditioned on a condition being true while other execution is conditioned upon it being false.</p>
<p>On the other hand, I don't think there's necessarily anyhing magical about the &quot;if/else&quot; paradigm.  In some cases, it might be useful to design a language around flags and combinations thereof, where instead of writing something like:</p>
<pre><code>if (x==y)
{
  equalAct1();
  commonAct1();
  equalact2();
}
else
{
  unequalAct1();
  commonAct1();
  unequalact2();
}
</code></pre>
<p>one could instead write:</p>
<pre><code>            setflag equalPos (x==y)
equalPos:   equalAct1();
!equalPos:  unequalAct1();
            commonAct1();
equalPos:   equalAct2();
!equalPos:  unequalAct2();
</code></pre>
<p>For many tasks, repeating execution conditions would be far more trouble than it would be worth, but for some tasks involving many combinations of conditions which should be handled almost identically, being able to separate out what pieces of code should execucte for what combinations of conditions might be helpful.</p>

CC BY-SA 4.0
2023-11-05T20:17:20.343Z
2023-11-05T20:17:20.343Z
supercat
CC BY-SA 4.0
2023-11-10T14:42:22.807Z
This could be [structured in/with tables](https://langdev.stackexchange.com/a/2397/903), if tables ever come to source code.
Pablo H
CC BY-SA 4.0
2023-11-10T15:51:14.863Z
@PabloH: That reminds me of something I've long thought (for almost 30 years), which is that programming languages should allow embedding of formatting information via standard means.  At the time, I was mainly coding in assembly language rather than C, and the interest would have been having a means by which text files could indicate to editors how they should set up things like tab stops, but I would also want a means of auto-formatting comment sections to the right of a block of code.  Nowadays, I think other details are more important, such as allowing identifiers...
supercat
CC BY-SA 4.0
2023-11-10T15:54:31.890Z
...to have a canonical name spelled with ASCII text as well as an optional human-readable name which may be shown using whatever representation is most understandable for humans.  If a program which uses e.g. Hebrew human-readable identifiers needs to be read by someone who doesn't know Hebrew, showing the code with canonical names would allow someone who doesn't know Hebrew to edit the code without having to know the Hebrew alphabet and how to type all the letters therein.
supercat
# Else-statements
Posted by: username_0 on 2023-11-05
Let's say your designing a new language with syntax and semantics similare to other C-style languages (C#, Java, C++, JS, etc). You want the language to have `if`-statements.

Does it need support for `else`-statements? Is there anything you can't do with the early return design pattern?

**edit**

The question was if you could design a new language without else statements, or if there would be some algoritms in such a language that would be impossible to code. In other words; is else necessary or simply a convenience?
**Tags:** language-design
> **Comments:**
> **username_1**: `else` is not a kind of statement, it is a part of an `if` statement. There is no language I know of where you can write `else` as a statement by itself. Your question also doesn't say what you mean by "need" ─ need for what purpose? If the goal is only to have "syntax and semantics similar to other C-style languages" then the answer is yes or no depending on what you mean by "similar". It's also unclear what benefit you might expect from a language *not* having `else` clauses.  
> **username_2**: While the question is on topic IMO, it is extremely trivial; as @kaya3 said, what benefit is there *not* to have `else`?  
> **username_3**: Nonetheless, the answer would be "no", because you can evaluate the predicate into a local variable and then have a second if with a not to mimic the behavior of the else part. However, nobody would do that because it would require extra code and real code would likely have a performance penalty because users would reevaluate predicates.  
> **username_4**: @kaya3: In some interpreted languages, an "if" statement doesn't contain other statements, but rather manipulates a combination of state variables which suppresses normal execution of other statements unless/until an "else" or "endif" is executed.  
> **username_0**: The question was if you could design a new language without `else` statements, or if there would be some algoritms in such a language that would be impossible to code. In other words; is `else` necessary or simply a convenience?  
> **username_5**: @Knarf Well as the answer shows a second if with just the same condition inverted could be a substitute for `else` in all cases... but of course that would be slower and more verbose and less readible than just having an `else` statement.  
> **username_6**: @Knarf In that case, I think what you want is [Turing-completeness](https://en.wikipedia.org/wiki/Turing_completeness). (In short, it's a convenience.)  
---
## 2 answers
### Answer by username_7 on 2023-11-05. Score: 4
Consider a typical conditional statement.
if (condition) {
    // Do stuff if true
} else {
    // Do stuff if false
}

In general, you should be able to rewrite this to not use else.
let c = condition;
if (c) {
    // Do stuff if true
}
if (!c) {
    // Do stuff if false
}

Replacing else with an early return gets a little trickier.
if (some_environment_variable()) {
    os.write_to_file("The environment variable is true!")
} else {
    os.write_to_file("The environment variable is false.")
}

os.write_to_file("Both cases considered!")

This could be transformed to
fn test_env_var() {
    if (some_environment_variable()) {
        os.write_to_file("The environment variable is true!")
        return
    }
    os.write_to_file("The environment variable is false!")
    return
}

test_env_var();
os.write_to_file("Both cases considered!")

But just because you can do this does not mean you should. Examples in the real world are not as trivial as these. Imagine being forced to write 10 different functions with early returns instead of a simple if/else chain.
> **Comments:**
> **username_8** (2023-11-07): I'm not an adherent, but the proponents of else-less programming would probably disagree with you.  
---
### Answer by username_4 on 2023-11-05. Score: 0
The ability to evaluate conditions and have different portions of the following code execute based upon their values is useful, and would be far less useful if the it were not possible to have some code's execution conditioned on a condition being true while other execution is conditioned upon it being false.
On the other hand, I don't think there's necessarily anyhing magical about the "if/else" paradigm.  In some cases, it might be useful to design a language around flags and combinations thereof, where instead of writing something like:
if (x==y)
{
  equalAct1();
  commonAct1();
  equalact2();
}
else
{
  unequalAct1();
  commonAct1();
  unequalact2();
}

one could instead write:
            setflag equalPos (x==y)
equalPos:   equalAct1();
!equalPos:  unequalAct1();
            commonAct1();
equalPos:   equalAct2();
!equalPos:  unequalAct2();

For many tasks, repeating execution conditions would be far more trouble than it would be worth, but for some tasks involving many combinations of conditions which should be handled almost identically, being able to separate out what pieces of code should execucte for what combinations of conditions might be helpful.
> **Comments:**
> **username_9** (2023-11-10): This could be [structured in/with tables](https://langdev.stackexchange.com/a/2397/903), if tables ever come to source code.  
> **username_4** (2023-11-10): @PabloH: That reminds me of something I've long thought (for almost 30 years), which is that programming languages should allow embedding of formatting information via standard means.  At the time, I was mainly coding in assembly language rather than C, and the interest would have been having a means by which text files could indicate to editors how they should set up things like tab stops, but I would also want a means of auto-formatting comment sections to the right of a block of code.  Nowadays, I think other details are more important, such as allowing identifiers...  
> **username_4** (2023-11-10): ...to have a canonical name spelled with ASCII text as well as an optional human-readable name which may be shown using whatever representation is most understandable for humans.  If a program which uses e.g. Hebrew human-readable identifiers needs to be read by someone who doesn't know Hebrew, showing the code with canonical names would allow someone who doesn't know Hebrew to edit the code without having to know the Hebrew alphabet and how to type all the letters therein.  
---
