O que você acha dessa nova sintaxe if-then [fechada]

Eu só estava pensando em algo que seria muito legal de ter nos meus controles if-elif-else.

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

Então, basicamente, um thenserá executado quando qualquer uma das condições for executada, EXCETO a condição else. Você acha que isso é útil? É semelhante ao try-except-else do python.

Eu acho que alguns de vocês estão sugerindo uma implementação muito preliminar. O thenbloco seria como o elsebloco de um try-exceptbloco em python. A verdadeira razão pela qual sugiro isso é para situações como essa.

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

O thenbloco tem o escopo definido para o primeiro, exatamente como o elseé. Portanto, o aninhamento funciona bem. E se você precisar executar um método antes das instruções if, isso realmente não tem nada a ver com este caso de uso.

Eu acho que parece horrível. Se você deseja que o código seja executado após uma variedade de condições, (a) verifique novamente essas condições ou (b) defina uma variável para o status de sucesso indicado.

Geralmente, você já pode fazer isso com um switch / case e um switch / case fornece um controle mais preciso sobre o que você está propondo.

Também não lê corretamente logicamente. Se A mais se B, então C. Não implica a alguém que C será executado se A ou B avaliarem como verdadeiro.

Interessante, mas me parece (reconhecidamente um pouco definido), um convite para problemas de legibilidade, lógica e sintaxe.

Edit: Seu if-elif é muito simples - e se houvesse 10 elifs? 20? Todas as condições precisariam ser verdadeiras? Quais são as chances disso?
Seu if-elif é muito simples - e se houvesse 10 elifs? 20? Isso não tornaria isso ilegível?

Além disso, pode ser facilmente alcançado pela metodologia estabelecida testada e comprovada:

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

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

O que acontece se "stuff_that_applies_to_both" precisar acontecer antes das etapas individuais? Seu código não lida com 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();
}

Por fim, essa sintaxe permite maior flexibilidade com mais condições: if (thisCondition ou thatCondition ou outraCondition) {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();
}

Eu tenho usado if / else, mas poderia ter usado tão facilmente uma instrução switch com um sinalizador:

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

Observe que, na verdade, eu não precisava do sinalizador conditionApplies - eu poderia ter adicionado a função "stuff_that_applies_to_both ()" a ambas as condições não padrão - apenas fiz isso para que pareça mais com a sintaxe definida acima, embora com o "then" ao invés do "outro".

Portanto, parece-me uma sintaxe muito especializada, onde uma sintaxe mais geral preenche a conta e muito mais.

+1 por pensar em um recurso possível (continue fazendo isso!), Mas eu não votaria para implementá-lo.

Hoje eu não me importaria de usar algo assim. Mas, para ter certeza, eu o usaria tantas vezes quanto repito até.

O código pareceria pelo menos melhor sem o aninhamento supérfluo. Embora eu prefira Else Ifa elif. Eu substituiria o Thencom Doe o final Elsepor Otherwise.

Parece uma ideia legal. No entanto, o único problema que imagino é que você é mais propenso a erros. Como escrever um if / else if e chamar blah () então. Escreva um outro extra se isso não quiser blá, removendo blá e adicione-o aos seus ifs / elseifs. Então, quando você ou outro programador adicionar outra declaração, poderá esperar que blá seja chamado, mas não.

Ou você pode ter vários ifs, escrever um blá e esquecer todos os ifs, exceto um que exige isso, o que quebraria alguma coisa. Também há chances de que você precise seguir todos os itens, se você o colocar sob o bloco if. Possivelmente definindo um bool em else (NoUpdate = true) e basta escrever um if (! NoUpdate) {} diretamente sob o qual é mais claro e pode ser definido por um if

Só estou dizendo que parece mais propenso a erros, não que eu não goste da idéia. Eu não me importaria de vê-lo em um idioma, mas não consigo imaginar nenhuma situação em que eu o usaria se meu idioma o apoiar.

Acho sua sintaxe confusa, mas vejo algum valor no conceito. Conceitualmente, quando considero o problema, o que me vejo querendo é um "descuidado", que basicamente executaria coisas nos casos em que o último elsenão foi acionado . Olhando por esse ângulo, sugiro que se possa obter um resultado semelhante via:

  Faz
  {
    se (condição1)
      ... apenas para condição1
    senão se (condição2)
      ... material apenas para condition2
    outro
    {
      ... material para nenhuma das condições
      pausa;
    }
    ... coisas para ambas as condições
  } enquanto (0); // Ponto de continuação do intervalo

Outra opção pode, em alguns casos, ser:

  if ((condição1 e& (ação1,1)) ||
       (condição2 e& (ação2,1)) ||
       (action_for_neither, 0))
    action_for_either;

Um pouco desagradável, mas em alguns casos pode não haver uma boa maneira de expressar a sequência desejada de eventos além de duplicar o código ou usar goto(o que pode não ser tão ruim, exceto pelo desenho animado que alguém possa inserir aqui).