Alguma outra linguagem diferente de JavaScript tem uma diferença entre os locais de início da chave (mesma linha e próxima linha)?

Hoje, enquanto eu estava lendo aleatoriamente o livro da O'Reilly sobre padrões de JavaScript, descobri uma coisa interessante (página 27 para referência).

Em Javascript, em alguns casos, há uma diferença se o local de início da chave for diferente.

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

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

Enquanto

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

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

JSfiddle Demo

Alguma outra língua por aí tem esse comportamento? Se sim, então eu teria que mudar meu hábito com certeza .. :)

Estou principalmente preocupado com PHP, C, C ++, Java e ruby.

Qualquer linguagem que não dependa de ponto-e-vírgula (mas em vez de novas linhas) para delimitar as instruções permite isso. Considere Python :

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

Você pode ser capaz de construir um caso semelhante no Visual Basic, mas de repente não consigo descobrir como porque o VB é muito restritivo em onde os valores podem ser colocados. Mas o seguinte deve funcionar, a menos que o analisador estático reclame sobre código inacessível:

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

Das linguagens que você mencionou, Ruby tem a mesma propriedade. PHP, C, C ++ e Java não simplesmente porque descartam a nova linha como espaço em branco e exigem ponto-e-vírgula para delimitar as instruções.

Aqui está o código equivalente do exemplo Python em Ruby:

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

O interpretador JavaScript adiciona automaticamente um ;no final de cada linha se não encontrar um (com algumas exceções, não entrando nelas aqui :).

Então, basicamente, o problema não é a localização dos colchetes (que aqui representam um objeto literal, não um bloco de código como na maioria das linguagens), mas este pequeno "recurso" que força seu primeiro exemplo a return ;=> undefined. Você pode verificar o comportamento de return na especificação ES5 .

Para outras linguagens com comportamento semelhante, verifique a resposta de Konrad .

Certamente. A linguagem de programação go do Google exibe um comportamento muito semelhante (embora com efeitos diferentes). Conforme explicado lá:

Na verdade, o que acontece é que a linguagem formal usa ponto-e-vírgula, assim como em C ou Java, mas eles são inseridos automaticamente no final de cada linha que parece o final de uma instrução. Você não precisa digitá-los sozinho.

..recorte...

Essa abordagem torna o código de aparência limpa e sem ponto-e-vírgula. A única surpresa é que é importante colocar a chave de abertura de uma construção como uma instrução if na mesma linha de if; se não fizer isso, há situações que podem não ser compiladas ou podem dar o resultado errado. A linguagem força o estilo de chave em certa medida.

Secretamente, acho que Rob Pike só queria uma desculpa para exigir o One True Brace Style.

A resposta a essa pergunta é bastante fácil. Qualquer idioma com "inserção automática de ponto-e-vírgula" pode ter problemas nessa linha. O problema com isso

return
{
     name: 'rajat'
};

..é que o mecanismo js irá inserir um ponto-e-vírgula após a return;instrução (e, portanto, retornar undefined). Este exemplo é um bom motivo para abrir as chaves sempre do lado direito e nunca do lado esquerdo também. Como você já percebeu corretamente, se houver uma chave na mesma linha, o interpretador perceberá e não poderá inserir o ponto-e-vírgula.

FWIW, JSLint relata vários avisos com essa sintaxe:

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

A primeira linguagem em que me deparei com isso foi awk (que também tem sua parcela de "esquisitices" de sintaxe; ponto e vírgula opcional, concatenação de string usando apenas espaços em branco e assim por diante ...) Acho que os designers do DTrace, que basearam a sintaxe D vagamente no awk, tive bastante bom senso para NÃO copiar esses recursos, mas não consigo me lembrar de cara. Um exemplo simples (contando o número de tags ENTITY em um DTD, do meu 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

Se este pequeno script fosse escrito com a chave em uma linha própria, isto é o que aconteceria:

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