Função local vs Lambda C # 7.0

Estou observando as novas implementações no C # 7.0 e acho interessante que elas tenham implementado funções locais, mas não consigo imaginar um cenário em que uma função local seja preferida a uma expressão lambda e qual é a diferença entre as duas.

Entendo que lambdas são anonymousfunções enquanto funções locais não, mas não consigo descobrir um cenário do mundo real, em que a função local tenha vantagens sobre as expressões lambda

Qualquer exemplo seria muito apreciado. Obrigado.

Isso foi explicado por Mads Torgersen no C # Design Meeting Notes, onde as funções locais foram discutidas pela primeira vez :

Você quer uma função auxiliar. Você o está usando apenas de uma única função e provavelmente usa variáveis ​​e parâmetros de tipo que estão no escopo nessa função que contém. Por outro lado, ao contrário de um lambda, você não precisa dele como um objeto de primeira classe, portanto, não deseja atribuir a ele um tipo de delegado e alocar um objeto de delegado real. Além disso, você pode querer que seja recursivo ou genérico, ou implementá-lo como um iterador.

Para expandir um pouco mais, as vantagens são:

1. Atuação.

   Ao criar um lambda, é necessário criar um delegado, que é uma alocação desnecessária neste caso. Funções locais são realmente apenas funções, sem necessidade de delegados.

   Além disso, as funções locais são mais eficientes na captura de variáveis ​​locais: lambdas geralmente capturam variáveis ​​em uma classe, enquanto as funções locais podem usar uma estrutura (aprovada usando ref), o que evita novamente uma alocação.

   Isso também significa que chamar funções locais é mais barato e elas podem ser incorporadas, possivelmente aumentando ainda mais o desempenho.

2. As funções locais podem ser recursivas.

   Os lambdas também podem ser recursivos, mas requerem código estranho, onde você primeiro atribui nulla uma variável delegada e depois ao lambda. Funções locais podem naturalmente ser recursivas (incluindo recursivas mutuamente).

3. As funções locais podem ser genéricas.

   As lambdas não podem ser genéricas, pois precisam ser atribuídas a uma variável com um tipo concreto (esse tipo pode usar variáveis ​​genéricas do escopo externo, mas isso não é a mesma coisa).

4. Funções locais podem ser implementadas como um iterador.

   Lambdas não pode usar a palavra-chave yield return(e yield break) para implementar a IEnumerable<T>função -returning. Funções locais podem.

5. As funções locais parecem melhores.

   Isso não é mencionado na citação acima e pode ser apenas meu viés pessoal, mas acho que a sintaxe da função normal parece melhor do que atribuir um lambda a uma variável delegada. As funções locais também são mais sucintas.

   Comparar:

   int add(int x, int y) => x + y;
   Func<int, int, int> add = (x, y) => x + y;

Além da grande resposta de svick, há mais uma vantagem nas funções locais:
elas podem ser definidas em qualquer lugar da função, mesmo após a returndeclaração.

public double DoMath(double a, double b)
{
    var resultA = f(a);
    var resultB = f(b);
    return resultA + resultB;

    double f(double x) => 5 * x + 3;
}

Se você também quiser saber como testar a função local, verifique o JustMock, pois ele possui a funcionalidade para fazê-lo. Aqui está um exemplo simples de classe que será testado:

public class Foo // the class under test
{ 
    public int GetResult() 
    { 
        return 100 + GetLocal(); 
        int GetLocal () 
        { 
            return 42; 
        } 
    } 
}

E aqui está a aparência do teste:

[TestClass] 
public class MockLocalFunctions 
{ 
    [TestMethod] 
    public void BasicUsage() 
    { 
        //Arrange 
        var foo = Mock.Create<Foo>(Behavior.CallOriginal); 
        Mock.Local.Function.Arrange<int>(foo, "GetResult", "GetLocal").DoNothing(); 

        //Act 
        var result = foo. GetResult(); 

        //Assert 
        Assert.AreEqual(100, result); 
    } 
} 

Aqui está um link para a documentação do JustMock .

Aviso Legal. Eu sou um dos desenvolvedores responsáveis ​​pelo JustMock .

Uso funções in-line para evitar a pressão da coleta de lixo, especialmente quando se lida com métodos de execução mais longos. Digamos que você queira obter 2 anos ou dados de mercado para um determinado símbolo. Além disso, é possível incluir muitas funcionalidades e lógica de negócios, se necessário.

o que se faz é abrir uma conexão de soquete ao servidor e fazer um loop sobre os dados que vinculam um evento a um evento. Pode-se pensar da mesma maneira que uma classe é projetada, apenas uma não está escrevendo métodos auxiliares em todo o lugar que realmente estão trabalhando apenas para uma peça de funcionalidade. Abaixo está um exemplo de como isso pode parecer, observe que estou usando variáveis ​​e os métodos "helper" estão abaixo do finalmente. No Finalmente, removo bem os manipuladores de eventos, se minha classe do Exchange fosse externa / injetada, não haveria nenhum manipulador de eventos pendente registrado

void List<HistoricalData> RequestData(Ticker ticker, TimeSpan timeout)
{
    var socket= new Exchange(ticker);
    bool done=false;
    socket.OnData += _onData;
    socket.OnDone += _onDone;
    var request= NextRequestNr();
    var result = new List<HistoricalData>();
    var start= DateTime.Now;
    socket.RequestHistoricalData(requestId:request:days:1);
    try
    {
      while(!done)
      {   //stop when take to long….
        if((DateTime.Now-start)>timeout)
           break;
      }
      return result;

    }finally
    {
        socket.OnData-=_onData;
        socket.OnDone-= _onDone;
    }


   void _OnData(object sender, HistoricalData data)
   {
       _result.Add(data);
   }
   void _onDone(object sender, EndEventArgs args)
   {
      if(args.ReqId==request )
         done=true;
   } 
}

Você pode ver as vantagens mencionadas abaixo, aqui você pode ver uma implementação de amostra. Espero que ajude a explicar os benefícios.