Un autre langage que JavaScript a-t-il une différence entre les emplacements de début d'accolades (même ligne et ligne suivante)?

Aujourd'hui, alors que je lisais au hasard le livre O'Reilly sur les modèles JavaScript, j'ai trouvé une chose intéressante (page 27 pour référence).

En Javascript, dans certains cas, il y a une différence si l'emplacement de départ de l'accolade est différent.

function test_function1() {
    return
    {
        name: 'rajat'
    };
}

var obj = test_function1();
alert(obj);  //Shows "undefined"

Tandis que

function test_function2() {
    return {
        name: 'rajat'
    };
}

var obj = test_function2();
alert(obj); //Shows object

Démo JSfiddle

Y a-t-il un autre langage qui ait un tel comportement? Si tel est le cas, je devrais certainement changer d’habitude .. :)

Je suis principalement préoccupé par PHP, C, C ++, Java et ruby.

Tout langage qui ne repose pas sur des points-virgules (mais plutôt sur des nouvelles lignes) pour délimiter des instructions le permet potentiellement. Considérez Python :

>>> def foo():
...   return
...   { 1: 2 }
... 
>>> def bar():
...   return { 1: 2 }
... 
>>> foo()
>>> bar()
{1: 2}

Vous pourrez peut-être créer un cas similaire dans Visual Basic, mais je ne peux pas comprendre comment, car VB est assez restrictif dans l'emplacement des valeurs. Mais ce qui suit devrait fonctionner, sauf si l'analyseur statique se plaint d'un code inaccessible:

Try
    Throw New Exception()
Catch ex As Exception
    Throw ex.GetBaseException()
End Try

' versus

Try
    Throw New Exception()
Catch ex As Exception
    Throw
    ex.GetBaseException()
End Try

Parmi les langues que vous avez mentionnées, Ruby a la même propriété. PHP, C, C ++ et Java ne le font pas simplement parce qu'ils rejettent le retour à la ligne en tant qu'espace blanc et nécessitent des points-virgules pour délimiter les instructions.

Voici le code équivalent de l'exemple Python dans Ruby:

>> def foo
>>   return { 1 => 2 }
>> end
=> nil
>> def bar
>>   return
>>   { 1 => 2 }
>> end
=> nil
>> foo
=> {1=>2}
>> bar
=> nil

L'interpréteur JavaScript ajoute automatiquement un ;à la fin de chaque ligne s'il n'en trouve pas (à quelques exceptions près, sans y entrer ici :).

Donc, fondamentalement, le problème n'est pas l'emplacement des accolades (qui représentent ici un objet littéral, pas un bloc de code comme dans la plupart des langages), mais cette petite "fonctionnalité" qui oblige votre premier exemple à return ;=> undefined. Vous pouvez vérifier le comportement de return dans la spécification ES5 .

Pour d'autres langues qui ont un comportement similaire, consultez la réponse de Konrad .

Certainement. Le langage de programmation go de Google présente un comportement très similaire (bien qu'avec des effets différents). Comme expliqué ici:

En fait, ce qui se passe, c'est que le langage formel utilise des points-virgules, un peu comme en C ou Java, mais ils sont insérés automatiquement à la fin de chaque ligne qui ressemble à la fin d'une instruction. Vous n'avez pas besoin de les saisir vous-même.

..couper...

Cette approche permet d'obtenir un code propre et sans point-virgule. La seule surprise est qu'il est important de mettre l'accolade ouvrante d'une construction telle qu'une instruction if sur la même ligne que if; si vous ne le faites pas, certaines situations risquent de ne pas se compiler ou de donner un résultat erroné. La langue impose dans une certaine mesure le style d'accolade.

Secrètement, je pense que Rob Pike voulait juste une excuse pour exiger le style One True Brace.

La réponse à cette question est assez simple. Toute langue qui a «l'insertion automatique de point-virgule» peut être en difficulté sur cette ligne. Le problème avec ça

return
{
     name: 'rajat'
};

..est que le moteur js insérera un point-virgule après l' return;instruction (et donc retournera undefined). Cet exemple est une bonne raison d'ouvrir les accolades toujours du côté droit et jamais du côté gauche également. Comme vous l'avez déjà correctement remarqué, s'il y a un crochet dans la même ligne, l'interprétateur le remarquera et ne pourra pas insérer un point-virgule.

FWIW, JSLint signale plusieurs avertissements avec cette syntaxe:

$ jslint -stdin
function foo(){
  return
  { x: "y" };
}
^D
(3): lint warning: unexpected end of line; it is ambiguous whether these lines are part of the same statement
  return
........^

(3): lint warning: missing semicolon
  { x: "y" };
..^

(3): lint warning: unreachable code
  { x: "y" };
..^

(3): lint warning: meaningless block; curly braces have no impact
  { x: "y" };
..^

(3): lint warning: use of label
  { x: "y" };
.....^

(3): lint warning: missing semicolon
  { x: "y" };
...........^

(3): lint warning: empty statement or extra semicolon
  { x: "y" };
............^


0 error(s), 7 warning(s)

Le premier langage où je suis tombé sur ceci était awk (qui a aussi sa part de syntaxe "bizarreries"; points-virgules optionnels, concaténation de chaînes en utilisant uniquement des espaces et ainsi de suite ...) Je pense que les concepteurs de DTrace, qui ont basé la syntaxe D de manière lâche sur awk, avait assez de sens pour NE PAS copier ces fonctionnalités, mais je ne me souviens pas du haut de ma tête. Un exemple simple (compter le nombre de balises ENTITY dans une DTD, depuis mon Mac):

$ cat printEntities.awk 
# This prints all lines where the string ENTITY occurs
/ENTITY/ {
  print $0
}
$ awk -f printEntities.awk < /usr/share/texinfo/texinfo.dtd | wc -l
     119

Si ce petit script était à la place écrit avec l'accolade sur une ligne propre, voici ce qui se passerait:

$ cat printAll.awk 
# Because of the brace placement, the print statement will be executed
# for all lines in the input file
# Lines containing the string ENTITY will be printed twice,
# because print is the default action, if no other action is specified
/ENTITY/
{ 
   print $0 
}
$ awk -f printAll.awk < /usr/share/texinfo/texinfo.dtd | wc -l
     603
$ /bin/cat < /usr/share/texinfo/texinfo.dtd | wc -l
     484
$