¿Algún otro idioma que no sea JavaScript tiene una diferencia entre las ubicaciones de inicio de las llaves (la misma línea y la siguiente)?

Hoy, mientras leía al azar el libro de patrones de JavaScript O'Reilly, encontré algo interesante (página 27 como referencia).

En Javascript, en algunos casos, hay una diferencia si la ubicación de inicio de la riostra es diferente.

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

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

Mientras

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

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

Demostración de JSfiddle

¿Hay algún otro idioma que tenga ese comportamiento? Si es así, seguro que tendría que cambiar mi hábito .. :)

Me preocupa principalmente PHP, C, C ++, Java y ruby.

Cualquier lenguaje que no se base en punto y coma (sino en líneas nuevas) para delimitar declaraciones potencialmente permite esto. Considere Python :

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

Es posible que pueda construir un caso similar en Visual Basic, pero en la parte superior de mi cabeza no puedo entender cómo porque VB es bastante restrictivo en el lugar donde se pueden colocar los valores. Pero lo siguiente debería funcionar, a menos que el analizador estático se queje de un código inalcanzable:

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

De los idiomas que mencionaste, Ruby tiene la misma propiedad. PHP, C, C ++ y Java no lo hacen simplemente porque descartan la nueva línea como espacios en blanco y requieren punto y coma para delimitar las declaraciones.

Aquí está el código equivalente del ejemplo de Python en Ruby:

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

El intérprete de JavaScript agrega automáticamente un ;al final de cada línea si no encuentra uno (con algunas excepciones, no los ingresa aquí :).

Básicamente, el problema no es la ubicación de las llaves (que aquí representan un objeto literal, no un bloque de código como en la mayoría de los lenguajes), sino esta pequeña "característica" que obliga a su primer ejemplo a return ;=> undefined. Puede consultar el comportamiento de return en la especificación ES5 .

Para otros idiomas que tienen un comportamiento similar, consulte la respuesta de Konrad .

Seguramente. El lenguaje de programación go de Google exhibe un comportamiento muy similar (aunque con diferentes efectos). Como se explica allí:

De hecho, lo que sucede es que el lenguaje formal usa punto y coma, como en C o Java, pero se insertan automáticamente al final de cada línea que parece el final de una declaración. No es necesario que los escriba usted mismo.

..recorte...

Este enfoque permite obtener un código limpio y sin punto y coma. La única sorpresa es que es importante colocar la llave de apertura de una construcción como una declaración if en la misma línea que la if; si no lo hace, hay situaciones que pueden no compilarse o pueden dar un resultado incorrecto. El lenguaje fuerza el estilo de corsé hasta cierto punto.

En secreto, creo que Rob Pike solo quería una excusa para requerir el One True Brace Style.

La respuesta a esa pregunta es bastante sencilla. Cualquier idioma que tenga "inserción automática de punto y coma" podría tener problemas en esa línea. El problema con esto

return
{
     name: 'rajat'
};

..es que el motor js insertará un punto y coma después de la return;declaración (y por lo tanto, regresará undefined). Este ejemplo es una buena razón para abrir las llaves siempre en el lado derecho y nunca también en el lado izquierdo. Como ya lo notó correctamente, si hay un corchete en la misma línea, el interpretador lo notará y no podrá insertar un punto y coma.

FWIW, JSLint informa varias advertencias con esa sintaxis:

$ 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)

El primer idioma en el que encontré esto fue awk (que también tiene su parte de "rarezas" de sintaxis; punto y coma opcionales, concatenación de cadenas usando solo espacios en blanco, etc.) Creo que los diseñadores de DTrace, que basaron la sintaxis D libremente en awk, tuve suficiente sentido común para NO copiar estas características, pero no puedo recordarlo de la parte superior de mi cabeza. Un ejemplo simple (contando el número de etiquetas ENTITY en un DTD, desde mi 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 este pequeño script en cambio se escribiera con la llave en una línea propia, esto es lo que sucedería:

$ 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
$