What do you think of this new if-then syntax

Question

I was just thinking of something that would be really cool to have in my if-elif-else controls.

if condition:
    stuff()
elif condition:
    otherstuff()
then:
    stuff_that_applies_to_both()
else:
    stuff_that_doesnt_aply_to_either()

So basically a then will be run when any of the conditions are run EXCEPT the else condition. Do you think this is useful? It's similar to the try-except-else of python.

I think some of you are nitpicking a very preliminary implementation. The then block would be just like the else block in a try-except block in python. The real reason I suggest this is for situations like this.

m = {}
if condition == '1':
    m['condition'] = condition
elif condition2 == '3':
    m['condition2'] = condition2
elif condition3 == 'False':
    m['condition3'] = True
then:
    run_test_that_relies_on_one_of_the_conditions_being_true()

return m

The then block is scoped to the first if just like the else is. So nesting works fine. And if you need to run a method before the if statements, that really has nothing to do with this use case.

Answer 1

I think it looks horrible. If you want code to run after a variety of conditions then either (a) recheck those conditions or (b) set a variable to indicated success status.

Answer 2

Generally you can already do this with a switch/case and a switch/case provides more fine tuned control over what you are proposing.

It also doesn't read properly logically. If A else if B then C. Doesn't imply to someone that C will be executed if either A or B evaluate to true.

Answer 3

Interesting, but seems to me (admittedly somewhat set in my ways) an invitation for readability, logic, and syntax problems.

Edit: Your if-elif is very simple - what if there were 10 elifs? 20? Would all conditions need to be true? What are the chances of that?
Your if-elif is very simple - what if there were 10 elifs? 20? Wouldn't that make this fairly unreadable?

Also, can easily be achieved by tried-and-true established methodology:

if (thisCondition or thatCondition)
{
  if (thisCondition)
     stuff();
  else
     otherstuff();

    stuff_that_applies_to_both();
}
else
{
    stuff_that_doesn't_aply_sic_to_either();
}

What happens if "stuff_that_applies_to_both" needs to happen before the individual steps? Your code doesn't handle this case:

if (thisCondition or thatCondition)
{
  stuff_that_applies_to_both();

  if (thisCondition)
     stuff();
  else
     otherstuff();
}
else
{
    stuff_that_doesn't_aply_sic_to_either();
}

Finally, this syntax allows for greater flexibility with more conditions: if (thisCondition or thatCondition or anotherCondition) { stuff_that_applies_to_all();

  // Any combination of the three conditions using 
  // whichever logical syntax you'd like here
  if (thisCondition and anotherCondition)
     stuff();
  else if (thisCondition or thatCondition)
     stuff_number_2();
  else
     otherstuff();
}
else
{
    stuff_that_doesn't_aply_sic_to_either();
}

I have been using if/else, but could have as easily used a switch statement with a flag:

Boolean conditionApplies = true;

switch (someConditionToCheck)
{
    case thisCondition:
      stuff();
      break;

    case thatCondition:
        otherStuff();
        break;

    default:
        stuff_that_doesnt_aply_sic_to_either();
        conditionApplies = false;
        break;
}

if (conditionApplies)
    stuff_that_applies_to_both();

Note that I didn't actually need the conditionApplies flag - I could have added the "stuff_that_applies_to_both()" function to both the non-default conditions - I just did this so it looks more like the syntax defined above, albeit the "then" rather than the "else".

Therefore, it seems to me to be a very specialized syntax, where a more general syntax fills the bill and more.

+1 for thinking of a possible feature (keep doing that!), but I wouldn't vote to implement it.

Answer 4

I wouldn't mind using something like this myself today. But, to be sure I'd use it about as often as I use repeat until.

Code would at least look better without the superfluous nesting. Although I prefer Else If to elif. I'd replace the Then with Do and the final Else with Otherwise.

Answer 5

It seems like a cool idea. However the only problem i imagine is you are more prone to bugs. Like writing an if/else if and calling blah() in then. Writing an extra else if that doesnt want blah, removing blah from then and adding it to your ifs/elseifs. Then when you or another programmer add another statement you may expect blah to be called but not.

Or you can have several ifs, write a blah and forget all ifs but one require this which would break something. Also chances are if you need them to follow every if you'll put it under the if block. Possibly setting a bool in else (NoUpdate=true) and just write a if(!NoUpdate) {} directly under which is clearer and can be set by an if

I am just saying it seems more prone to bugs, not that i dont like the idea. I wouldnt mind seeing it in a language but i cant imagine any situtaion where i would use it if my language does support it.

Answer 6

I find your syntax confusing, but I see some value in the concept. Conceptually, when I've considered the issue, what I've found myself wanting is an "unelse", which basically would execute things in the cases where the last else didn't fire. Looking at it from that angle, I would suggest that one could achieve a similar result via:

  do
  {
    if (condition1)
      ... stuff for condition1 only
    else if (condition2)
      ... stuff for condition2 only
    else
    {
      ... stuff for neither condition
      break;
    }
    ... stuff for both conditions
  } while(0); // Continuation point for break

Another option may in some cases be:

  if ( ( condition1 && (action1,1)) ||
       ( condition2 && (action2,1)) ||
       (action_for_neither,0))
    action_for_either;

A bit nasty looking, but in some cases there may not be any good way of expressing the desired sequence of events other than duplicating code or using goto (which might not be so bad, except for the cartoon someone might insert here).