¿Qué opinas de esta nueva sintaxis if-then [cerrado]

Estaba pensando en algo que sería genial tener en mis controles if-elif-else.

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

Entonces, básicamente thense ejecutará a cuando cualquiera de las condiciones se ejecute EXCEPTO la condición else. ¿Crees que esto es útil? Es similar al try-except-else de python.

Creo que algunos de ustedes están haciendo una implementación muy preliminar. El thenbloque sería como el elsebloque en un try-exceptbloque en Python. La verdadera razón por la que sugiero esto es para situaciones como esta.

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

El thenbloque está limitado al primero si es como elsees. Entonces anidar funciona bien. Y si necesita ejecutar un método antes de las declaraciones if, eso realmente no tiene nada que ver con este caso de uso.

Creo que se ve horrible. Si desea que el código se ejecute después de una variedad de condiciones, entonces (a) vuelva a verificar esas condiciones o (b) establezca una variable en el estado de éxito indicado.

En general, ya puede hacer esto con un interruptor / caja y un interruptor / caja proporciona un control más ajustado sobre lo que está proponiendo.

Tampoco se lee correctamente lógicamente. Si A más si B, entonces C. no implica para alguien que C se ejecutará si A o B se evalúan como verdaderos.

Interesante, pero me parece (sin duda, algo en mi camino) una invitación a problemas de legibilidad, lógica y sintaxis.

Editar: su if-elif es muy simple: ¿qué pasaría si hubiera 10 elifs? 20? ¿Todas las condiciones tendrían que ser verdad? ¿Cuáles son las posibilidades de eso?
Tu if-elif es muy simple: ¿qué pasaría si hubiera 10 elifs? 20? ¿No haría eso bastante ilegible?

Además, se puede lograr fácilmente mediante una metodología establecida probada y verdadera:

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

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

¿Qué sucede si "stuff_that_applies_to_both" necesita suceder antes de los pasos individuales? Su código no maneja este caso:

if (thisCondition or thatCondition)
{
  stuff_that_applies_to_both();

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

Finalmente, esta sintaxis permite una mayor flexibilidad con más condiciones: if (thisCondition o thatCondition u otherCondition) {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();
}

He estado usando if / else, pero podría haber usado fácilmente una declaración de cambio con una bandera:

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();

Tenga en cuenta que en realidad no necesitaba el indicador conditionApplies: podría haber agregado la función "stuff_that_applies_to_both ()" a ambas condiciones no predeterminadas. Simplemente hice esto para que se parezca más a la sintaxis definida anteriormente, aunque el "entonces" en lugar del "más".

Por lo tanto, me parece una sintaxis muy especializada, donde una sintaxis más general llena la factura y más.

+1 por pensar en una posible característica (¡sigue haciendo eso!), Pero no votaría para implementarla.

Hoy no me importaría usar algo como esto. Pero, para estar seguro, lo usaría con la frecuencia que uso repetir hasta.

El código al menos se vería mejor sin la anidación superflua. Aunque prefiero Else Ifhacerlo elif. Reemplazaría el Thencon Doy el final Elsecon Otherwise.

Parece una buena idea. Sin embargo, el único problema que imagino es que eres más propenso a los errores. Como escribir un if / else if y llamar a blah () en ese momento. Escribir otro más si eso no quiere bla, eliminar bla de entonces y agregarlo a sus ifs / elseifs. Luego, cuando usted u otro programador agregue otra declaración, puede esperar que se llame a bla, pero no.

O puede tener varios ifs, escribir un bla y olvidar todos los ifs, pero uno requiere esto que rompería algo. También es probable que si necesita que lo sigan, lo colocará debajo del bloque if. Posiblemente estableciendo un bool en else (NoUpdate = true) y simplemente escriba un if (! NoUpdate) {} directamente debajo del cual es más claro y puede ser configurado por un if

Solo digo que parece más propenso a los errores, no es que no me guste la idea. No me importaría verlo en un idioma, pero no puedo imaginar ninguna situación en la que lo usaría si mi idioma lo admite.

Encuentro su sintaxis confusa, pero veo algo de valor en el concepto. Conceptualmente, cuando he considerado el problema, lo que he encontrado queriendo es un "desatino", que básicamente ejecutaría cosas en los casos en que el último elseno se disparara. Mirándolo desde ese ángulo, sugeriría que uno podría lograr un resultado similar a través de:

  hacer
  {
    si (condición1)
      ... cosas solo para la condición1
    si no (condición2)
      ... cosas solo para condition2
    más
    {
      ... cosas para ninguna condición
      descanso;
    }
    ... cosas para ambas condiciones
  } mientras (0); // Punto de continuación para el descanso

Otra opción puede ser en algunos casos:

  if ((condición1 && (acción1,1)) ||
       (condición2 && (acción2,1)) ||
       (action_for_neither, 0))
    action_for_either;

Parece un poco desagradable, pero en algunos casos puede que no haya una buena forma de expresar la secuencia de eventos deseada que no sea duplicar el código o usarlo goto(lo que puede no ser tan malo, excepto la caricatura que alguien podría insertar aquí).