Mar 26, 2014

Possíveis recursos do C# 6.0






Possiveis funcionalidades do C# 6.0


Sei que alguns desenvolvedores verão este post como notícia velha, mas eu me deparei com estas informaçoes hoje e as achei bem interessantes e acredito que estas podem ser úteis a mais desenvolvedores (mesmo porque não encontrei muito sobre o assunto em português), assim sendo, decidi postar sobre o assunto.


Se você deseja ver os posts originais (em inglês) veja estes links (ambos são baseados em um evento da Microsoft chamado NDC que ocorreu em Londres Dez/2013).


Os comentários representam a minha opnião (que pode não representar nada para você :)) e eu não sou, de forma alguma, um especialista em linguagens de programação (por exemplo não fiz esforço algum para verificar se as minhas sugestões não introduziriam ambiguidades na sintaxe da linguagem).


“Primary constructors”


class Exemplo
{
 public Exemplo (int valor, string nome)
 {
  this.valor = valor;
  this.nome = nome;
 }

 private int valor;
 private string nome;
}
C# 5.0


class Exemplo (int valor, string nome)
{
 private int valor;
 private string nome;
}
C# 6.0


Os seguintes pontos não ficaram claros para mim:

- será possível ter um corpo no construtor ?

- paramêtros com valor default (possivelmente sim) ?

- qual a visibilidade deste construtor? Assume a visibilidade da classe ?

- será possivel definir outros construtores ?


Já que o objetivo é simplificar porque não introduzir um conceito tipo “campos automáticos” ou mesmo “propriedades automáticas” permitindo assim reescrever o exemplo como:


class Exemplo (int valor, string nome) // Isto definiria os campos valor e nome.
{
}
C# 6.0


Propriedades (automaticas) somente leitura


class Exemplo
{
 public int PropriedadeSomenteLeitura { get; private set; }
}
C# 5.0


class Exemplo
{
 public int PropriedadeSomenteLeitura { get; } = um_campo_qualquer * UmMethodQualquer(1.0);
}
C# 6.0


Eu realmente não vejo muito ganho com isto. Prefiro a versão abaixo (já suportada atualment é claro)

(ok, eu sei que as mesmas não são semanticamente equivalentes, mas param mim, isto já é o suficiente)


class Exemplo
{
 public int PropriedadeSomenteLeitura { get; private set; }
}
C# 5.0


Outra questão é: o que pode ser usado como valor da propriedade? Qualquer expressão? Por exemplo, o código abaixo é válido?


class Exemplo
{
 public int PropriedadeSomenteLeitura { get; } = um_campo_qualquer * UmMethodQualquer(1.0);
}
C# 6.0


“Using” para membros estáticos


class Exemplo
{
 public double M()
 {
  return System.Math.Sqrt(1.0, 4.2);
 }
}
C# 5.0


using System.Math;

class Exemplo
{
 public double M()
 {
  return Sqrt(1.0, 4.2);
 }
}
C# 6.0


Sério? Java já suporta este recurso a algum tempo… e eu nunca gostei muito do mesmo… ;)


Property Expressions (não sei nem como traduzir isso)


class Exemplo
{
 public decimal ValorTotal { get { return Quantidade * ValorUnitario ; } }
}
C# 5.0


class Exemplo
{
 public decimal ValorTotal => Quantidade * ValorUnitario;
}
C# 6.0


  • Na minha opnião vivemos muito bem sem este recurso.

  • Péssimo nome (talvez Property Shortcut seria um nome mais descritivo)


“Method expressions”


class Exemplo1 
{ 
 public Point Move(int dx, int dy) 
 { 
  return new Point(X + dx, Y + dy); 
 } 
}
C# 5.0


class Exemplo1 
{ 
 public Point Move(int dx, int dy) => new Point(X + dx, Y + dy); 
}
C# 6.0


Mesma coisa que “property expressions”


Enumerables como parâmetros do tipo “params”


class Exemplo
{
 public void FazAlgo(params []MeuTipo items) { }
}
C# 5.0


class Exemplo
{
 public void FazAlgo(params IEnumerable<MeuTipo> items) { }
}
C# 6.0


Sem dúvida alguma, qualquer desenvolvedor que já tenha escrito métodos usando número de parâmetros variáveis (identificado pela palavra reservada params) sabe o quanto o mesmo é útil. Suportar IEnumerable<T> além de arrays torna os mesmos muito mais versáteis (pode-se passar qualquer coleção padrão!)


Dessa eu gostei pois não me obriga criar arrays só para poder chamar métodos como no exemplo acima (lembre-se que em C# arrays implementam IEnumerable<T> então, passar arrays, para métodos definidos como o exemplo acima, não exige conversões!


Checagem de “null” mais inteligente (ou “monadic null checking”, o que quer que isso queira dizer ;)


class Exemplo
{
 public int M(IList<string> ss)
 {
  if (ss != null)
  {
    var primeiraOuNulo = ss.FirstOrDefault();
    if (primeiraOuNulo != null)
     return primeiraOuNulo.Length;
  }
  return -1;
 }
}
C# 5.0


class Exemplo1
{
 public int M(IList<string> ss)
 {
  return ss?.FirstOrDefault()?.Length ?? -1;
 }
}
C# 6.0


Vamos acabar com o Natal! (afinal de contas, este tipo de sintaxe ajudaria em muito a por um fim em código tipo arvore de natal). Eu conheço alguns desenvolvedores que ficaram muito desapontados se este recurso for realmente incorporado à linguagem - já posso ver os argumentos de que agora o código esta mais complexo, não é trivial ;)


Ponto para a equipe do C#.


Inferência de tipos a partir de parêmtros de construtores


void M()
{
 var l = new List<string> { "Lista", "de", "strings" };
}
C# 5.0


void M()
{
 var l = new List { "Lista", "de", "strings" };
}
C# 6.0


Preciso dizer algo? Se você já desenvolveu aplicativos em C# com um nível de complexidade acima do trivial sabe o quanto é tedioso ficar lembrando o compilador sobre informações que ele já tem (ou que poderia facilmente obter). Mais um ponto para os designers da linguagem.


Alguns vão dizer que a linguágem X ou Y é muito melhor no quesito inferência de tipos; pode até ser verdade, mas eu uso o C# no dia-a-dia, não estas linguaguens ;), assim sendo, melhorias no sistema de inferência de tipos são bem vindas.


Declaração inline para parâmetros out


void M()
{
 int valor;
 if(Int32.TryParse("42", out valor))
  return valor;

 return -1;
}
C# 5.0


void M()
{
 return Int32.TryParse("42", out int valor) ? valor : -1;
}
C# 6.0


Hum.. este recurso me deixou em dúvida; embora eu entenda que esta mudança tem o potencial de diminuir a quantidade de código em certas construções comuns em programas (métodos no estilo TryParseXXXX() me vem a cabeça imediatamente) ainda receio que o ganho proporcionado seja menor que o risco de mau uso.


Compilador como serviço


De acordo com Anders Hejlsberg (neste vídeo +- 00:34), é possível que o projeto conhecido como Roslyn também seja liberado na próxima versão do Visual Studio! Se você ainda não deu uma olhada no mesmo, eu recomendo dedicar alguns minutos (possivelmente algumas horas :)) para fazê-lo! Outra solução semelhante é o NRefactory.


Agora que já discuti as possíveis funcionalidades da próxima versão do C# (pelo menos, segundo os posts que eu encontrei), gostaria de expor minha lista de desejos pessoal.


Funcionalidades que gostaria de ver na próxima versão do C#


Classes anônimas implementando interfaces


Se você já desenvolveu em Java provavelmente já fez uso deste recurso e possivelmente sabe o potencial para diminuir a quantidade de código escrito bem com simplificá-lo. Sinceramente, este é uma das poucas funcionalidades de Java que eu sinto falta no C#. Se você não tem idéia do que estou falando veja o exemplo abaixo:


public interface IFoo
{
 void DoIt();

 string Name { get; }
}

class Exemplo
{
 public void FazAlgo()
 {
  var itfImpl = new IFoo
  {
   void DoIt() { }

   string Name { get { return "name"; } }
  }
  
  System.Console.WriteLine(itfImpl.Name);
 }
}
Proposta


Em uma versão hipotética do C#, nas linhas 12 ~ 17 implementamos a interface IFoo anonimamente (ou seja, sem a necessidade de definir uma classe explicitamente).


Extension properties


Da mesma forma que extension methods podem simplificar, e muito, algums cenários de programação, acredito que o mesmo conceito aplicado à proriedades seria bastante útil (pelo menos eu já me deparei com algumas cituações onde o mesmo seria realmente muito bem vindo).


static class StringExtensions
{
 public static extension bool ContemAdriano
 { 
  get 
  {
   return value.Contains("Adriano");  // value representa a string.
            // Em nosso exemplo de chamada 
            // value representa o parâmetro 's'
  } 
 }
}

class Exemplo
{
 public bool FazAlgo(string s)
 {
  return s.ContemAdriano;
 }
}
Proposta


Interpolação de strings


Interpolação de strings permite a substituição de uma (ou mais) parte(s) de uma string pelo valor de uma variável de uma forma simples e intuitiva. Abaixo apresento um exemplo hipotético caso o conceito fosse suportado em C#:


class Exemplo
{
 public void FazAlgo()
 {
  int valor = 10;
  System.Console.WriteLine("Valor = $valor, Nome= $nome");
 }

 public string nome;
}
Proposta


O mesmo exemplo, hoje, pode ser escrito como:


class Exemplo
{
 public void FazAlgo()
 {
  int valor = 10;
  System.Console.WriteLine("Valor = {0}, Nome={1}", valor, nome);
 }

 public string nome;
}
C# 5.0


Apesar de algumas reservas, devido ao potencial de confusão em casos onde strings referenciem variáveis declaradas em um escopo distante, gostaria de ver esta funcionalidade na próxima versão do C#!


Modernização de algumas APIs da FCL


Ok, este ponto não tem nada a ver com a linguagem C# propriamente dita, mas já que estou reclamando, não custa nada incluir mais um item na lista de reclamações ;)


Eu admito: eu amo LINQ, e estou certo de que você, caso desenvolva aplicativos de tamanho razoável, também aprecia a elegância desta tecnologia; contudo, muitas das APIs da FCL não estão otimizadas para uso com LINQ. Um exemplo é a classe Regex e relaciondas (recentemente tenho usado as mesmas com bastante frequência); com mais frequencia do que eu gostaria eu me vejo escrevendo cógido como o exemplo abaixo:


var r = Regex.Matches("07/11/1990", "(?<componente>\d{2,4})+");
r.Groups.OfType<Group>().Where(...);

só porque a propriedade Groups é declarada como GroupCollection ao invés de IEnumerable<Group> ou algo parecido. Este é apenas um exemplo; existem muitas outras APIs que se beneficiariam se fossem refatoradas com LINQ em mente.


Antes que alguém reclame e me diga que eu posso implementar os operadores LINQ mais comuns esperando GroupCollection como parâmetro ao invés de IEnumerable<Group> gostaria de lembrá-lo que este é apenas um dos casos; só na família de classes relacionadas à regular expressions temos GroupCollection, CaptureCollection e MatchCollection; existe uma boa probabilidade de seu código depender de outras APIs da FCL que implementão coleções não padrão e, se isso ocorre, você terá que implementar operadores LINQ para elas também.


O que você acha de tudo isso? Quais funcionalidades você gostaria de ver implementadadas na próxima versão da linguágem?


Boa programação!

Mar 5, 2014

Running scripts on google drive documents

Hi.

I admit I have always looked to "cloud based" document editing (such as google drive, Microsoft Office 365, etc) with certain dislike, mainly due to the misconception that these applications would not allow me to use my precious scripts (after all, any true developer shall use scripts everywhere, right? ;)

Even though I somewhat disliked the idea, I ended up ceding (the convenience of having it available anywhere is so hard to ignore :) and,for some time, I have been using one spreadsheet to store a piece of information I use on a monthly basis.

It happens that last week I decided that one of the tasks involving that spreadsheet should be automated (basically, given some condition I'd like to add some information to a specific cell, which is a perfect job for a script) so I was considering moving the spreadsheet to my box and use LibreOffice (which I highly recommend, by the way) to edit it. 

While I was poking around my google spreadsheet menus, I stumbled in "Tools/Script Editor" menu option and realized that my resistance in using such online solutions had no ground whatsoever, i.e, it was just prejudice from my side :( I just selected that menu option and voila, scripts with debugging support!

That is all I needed! Some time (and a lot of keystrokes) later and I had my first script running; but the best was yet to come: not only I was able to reference my newly created function, but I could also schedule it to run from time to time! (that's exactly what I was looking for).

Following you can see my script:
function checkDate() {
  var ss = SpreadsheetApp.getActiveSpreadsheet();
  var sheet = ss.getSheets()[0];       
    
  var range = sheet.getRange("A1");
  
  var now = new Date();
  
  if (now.getHours() <= 10 || (now.getHours() >= 15 && now.getMinutes() > 30) || (now.getHours() >= 13 && (now.getHours() <= 14 && now.getMinutes() < 30)) ) {    
    range.setBackground("ORANGE");
    range.setValue("CLOSED");
  }
  else {
    range.setBackground("GREEN");
    range.setValue("OPEN");
  }
}
And it worked like a charm.

To my astonishment, today I figured it out that I can even execute WebServices (SOAP) from within my scripts (and of course I put it in action immediately) ! 

Happy Coding!

(Leia, uma versão extendida, deste post em portugues)

Executando scripts em documentos do google drive

(If you don't read Portuguese, you can read a simplified version of this post in english)

Ola.

Sempre tive certo "desdém" por soluções de edição de documentos (principalmente planilhas) nas "nuvens" (tipo google drive e/ou office 365), motivado, principalmente, por acreditar que as mesmas não me permitiriam incluir meus tão úteis scripts (afinal de contas, desenvolvedor que se prese tem que usar scripts em tudo ;)

Mesmo assim, ha algum tempo venho usando uma planilha no google drive para controlar ordens de pagamento; acontece que, na semana passada eu estava considerando passar a usar o LibreOffice (que por sinal eu recomendo) para fazer minhas edições nesta planilha pois eu queria modificar a cor de uma das células caso uma determinada condição fosse satisfeita (e isso, é claro, é tarefa para scripts). 

Não sei porque (ou como) eu acabei descobrindo que esta minha resistência em usar o google drive não passava de puro preconceito! Se você for no menu "Tools" (deve ser "Ferramentas" no bom e velho português) encontrará a opção "Script Editor"! Ou seja, pelo menos as planilhas do google drive, suportam scripts! E o melhor, até dupuração!)

Pronto! É tudo que eu precisava; depois de alguns minutos (e um punhado de teclas pressionadas) meu primeiro script estava pronto. E sabe da melhor? É possível referenciar scripts em fórmulas ou até mesmo agendar o mesmo para executar de tempo em tempo (exatamente o que eu buscava).

Abaixo segue o código que usei:
function checkDate() {
  var ss = SpreadsheetApp.getActiveSpreadsheet();
  var sheet = ss.getSheets()[0];       
    
  var range = sheet.getRange("A1");
  
  var now = new Date();
  
  if (now.getHours() <= 10 || (now.getHours() >= 15 && now.getMinutes() > 30) || (now.getHours() >= 13 && (now.getHours() <= 14 && now.getMinutes() < 30)) ) {    
    range.setBackground("ORANGE");
    range.setValue("FECHADO");
  }
  else {
    range.setBackground("GREEN");
    range.setValue("ABERTO");
  }
}
Hoje eu encontrei mais um motivo para eu criar mais um script nesta planilha: sempre que recebo ordens de pagamento eu quero saber a cotação do dolar no momento. Normalmente o que eu fazia era abrir o browser e navegar para algum site de cotação. 

O problema com esta solução é que a mesma é ...  digamos.... é manual (e não usa scripts :)). A solução mais óbvia para a questão? Encontrar alguma empresa que disponibilize a cotação do dolar através de um WebService e escrever um script para chamar este WebService.

Para minha surpresa, ao fazer uma busca na web, encontrei este post que descreve como acessar o WebService do Banco Central do Brasil (que eu nem imaginava que existisse) para obter tal informação. Perfeito, agora eu só tive que descobrir uma forma de executar o mesmo e fazer o parse dos dados retornados (o que não foi tão simples quanto parecia pois não consegui encontrar documentação do WebService em lugar algum).

O Código final ficou mais ou menos assim (não me preocupei em fazer tratamento de erros, muito menos em ser eficiente, só queria que o mesmo funcionasse :)
function getDolarExchangeRate() {
  Logger.clear();
  
  var wsdl = SoapService.wsdl("https://www3.bcb.gov.br/sgspub/JSP/sgsgeral/FachadaWSSGS.wsdl");  
  var service = wsdl.getService("FachadaWSSGSService");  
  var result = service.invokeOperation("getUltimosValoresSerieVO", ["1", "1"]);
    
  var i = 0;
  while (typeof result.Envelope.Body.multiRef[i] != 'undefined' ) {
    if (typeof result.Envelope.Body.multiRef[i].svalor != 'undefined')
      return result.Envelope.Body.multiRef[i].svalor.getText();
    i++;
  }
  
  return "Could not find 'svalor' element";
}
Agora tudo que tive  que fazer foi escolher uma célula na planilha e entrar a formula =getDolarExchangeRate() na mesma e bum, lá estava a cotação do dolar.

Happy Coding!

Feb 26, 2014

Utilitário útil da semana: Clip

Se você é um usuário do Windows um pouco mais avançado e utiliza o console (cmd.exe) é provável que recorra ao menu de contexto quando necessita copiar qualquer conteúdo do console para a área de transferência (clipboard) do Windows.  

Você sabia que o Windows (pelo menos a partir do Windows  7) vem com um utilitário chamado clip que permite que você copie qualquer conteúdo passado para sua entrada padrão (stdin) para a área de transferência? Por exemplo você pode copiar o resultado de um dir para o clipboard com a seguinte linha de comando:


c:\temp>dir | clip

É claro que você também pode redirecionar a entrada padrão:

c:\temp>clip < arquivo.txt
Não sei quanto a você, mas quando eu descobri este pequeno utilitário minha vida no console ficou muito mais fácil.

(Este post em Inglês)

Useful command line utility: Clip

Are you a heavy Windows console user? Have you ever copied the output from a program to the clipboard by using the context menu? Well, are you aware of clip.exe that comes with Windows (at least it is present on Windows 7 and newer) ? 

It simply copy whatever it gets from the standard input to the clipboard! So you can do things like:


c:\temp>dir | clip

And get the contents of dir output to the clipboard (and of course, now you can past it wherever you want)!

Of course you can also redirect the standard input:
c:\temp>clip < file.txt

Happy coding!

(this post in portuguese)

Oct 26, 2013

Closures in C# - Answer


In the previous post I've asked what would be the output of a simple C# application:

using System;
using System.Collections.Generic;
using System.Linq;

class Program
{
   private static void Main(string[] args)
   {
      foreach (var func in GetFuncs1())
      {
         Console.WriteLine("[first] {0}", func());
      }

      foreach (var func in GetFuncs2())
      {
         Console.WriteLine("[second] {0}", func());
      }
   }

   private static List<Func<int>> GetFuncs1()
   {
      var fs = new List<Func<int>>();

      for (int i = 0; i < 3; i++)
      {
         fs.Add(() => i);
      }
      return fs;
   }

   private static List<Func<int>> GetFuncs2()
   {
      var fs = new List<Func<int>>();

      foreach (var i in Enumerable.Range(0, 3))
      {
         fs.Add(() => i);
      }
      return fs;
    }  
}
The correct answer is: it depends!

In order to understand the issue you need to undertand Closures and captured variables in C# (for a deeper understanding about these subjects I recomed reading here and here).

Basically in both methods (GetFuncs1 and 2) we are creating lambda expressions that references a local variable (i); since the CLR garantees that the memory allocated for such variable will be reclaimed as soon as it is not referenced, i.e, long before the usage of the lambda expression, the C# compiler "captures" the variable (if you are curious about how it does it, open the assembly using ILDASM or ILSpy to inspect the IL code, I do recommend) and here start our issues.

As I said the compiler captures the variable, not its value; so, calling GetFuncs1() produces code that is equivalent to something like (see the highlighted lines 20, 25-28 and 29) (the actual code is quite different but for our purposes the following code can be seen as equivalent):

using System;
using System.Collections.Generic;

class Program
{
 private static void Main(string[] args)
 {
  foreach (var func in GetFuncs1())
  {
   Console.WriteLine("[first] {0}", func());
  }
 }

 private static List<Func<int>> GetFuncs1()
 {
  var fs = new List<Func<int>>();

  for (ret = 0; ret < 3; ret++)
  {
   fs.Add(ret_func);
  }
  return fs;
 }

 private static int ret_func()
 {
  return ret;
 }

 private static int ret;
}
That means that we are always calling ret_func() and this function will return the value of ret which is updated in the for loop!

Ok, so now you understand why the output was 3,3,3 but two questions come up (at least):

  1. Is there a way to avoid this behavior so the output would be 0, 1 and 2 ?
  2. Why the hell I said that the output of the program "depends" ? And more importantly, depends on what?
The answer for the first question is yes; simply declare a new variable inside the for loop and assign "i" to it (line 20), then return the value of this new variable from within the lambda expression (line 21) :
using System;
using System.Collections.Generic;

class Program
{
 private static void Main(string[] args)
 {
  foreach (var func in GetFuncs1())
  {
   Console.WriteLine("[first] {0}", func());
  }
 }

 private static List<Func<int>> GetFuncs1()
 {
  var fs = new List<Func<int>>();

  for (int i = 0; i < 3; i++)
  {
   var capture = i;
   fs.Add(() => capture);
  }
  return fs;
 }
}
Running the application now produces the expected result. What changed is that now, since we are creating a new variable in every iteration, the compiler will emit code equivalent to:
using System;
using System.Collections.Generic;

class Program
{
 private static void Main(string[] args)
 {
  foreach (var func in GetFuncs1())
  {
   Console.WriteLine("[first] {0}", func());
  }
 }

 private static List<Func<int>> GetFuncs1()
 {
  var fs = new List<Func<int>>();

  for (int i = 0; i < 3; i++)
  {
   var h = new Holder {value = i};
   fs.Add(h.GetIt);
  }
  return fs;
 }

 class Holder
 {
  public int value;

  public int GetIt()
  {
   return value;
  }
 }
}
Again, now it became pretty easy to understand why we get the expected output; in each iteration the compiler is simply instantiating a new object to hold the value of "i" at that point in time.

Ok, so from now on, everytime you create lambda expressions / anonymous functions that capture local variables I am sure you'll pay attention and make sure you get the behaviour you want.

Regarding the second point, i.e, the "depends" part, if this blog happens to have more than a few readers I am sure that, when running the program, some of you got "unexpected" different outputs twice (i.e, 3,3,3 and 2,2,2) while some of you got 3,3,3 and 0,1,2!

The difference? The version of the C# compiler used!

See the picture below:

It happens that in C# 5 the behavior for captured variables of a foreach loop has changed! In this case the compiler will emit code as if in each iteration a new local variable were allocated (the same trick I showed you before); if you followed me you now understand why when compiling with VS 2012 the code produced the expected result.

Now the 1 million dollars question: why on earth the version that uses a simple for has not been updated with the same behavior? Well, I don't have (and I don't pretend to have) the definitive answer. What I can say is that IMHO it is at least "confusing". New developers (which are most likely unaware of this behavior) will, invariably, be caught by this at least once (but it can be twice)!

If these new developers happen to first use a for loop (always with lambdas / anonymous methods capturing local variables) they may find themselves wondering why their lambdas/anonymous methods are observing the updated value of a captured variable and then, when they finally realize what's going on, they will tend to use the "declare a local variable in each iteration" trick everywhere (including in foreach loops). By the other hand if these developers happen to first use a foreach loop then they will most likely find themselves wondering why they observe different behaviors when using lambdas/anonymous methods!

Even though I understand the reasoning in this discussion I don't fully agree - parts of my brain still thinks this simply introduces inconsitencies - but this is just my opnion.

If you are interested in reading about this topic in the C# language specification, it can be found in chapter 8.8.4.

What do you think?

Closures em C# - Resposta


No post anterior eu deixei como pergunta qual seria a saída de um programa simples em C#:

using System;
using System.Collections.Generic;
using System.Linq;

class Program
{
   private static void Main(string[] args)
   {
      foreach (var func in GetFuncs1())
      {
         Console.WriteLine("[first] {0}", func());
      }

      foreach (var func in GetFuncs2())
      {
         Console.WriteLine("[second] {0}", func());
      }
   }

   private static List<Func<int>> GetFuncs1()
   {
      var fs = new List<Func<int>>();

      for (int i = 0; i < 3; i++)
      {
         fs.Add(() => i);
      }
      return fs;
   }

   private static List<Func<int>> GetFuncs2()
   {
      var fs = new List<Func<int>>();

      foreach (var i in Enumerable.Range(0, 3))
      {
         fs.Add(() => i);
      }
      return fs;
    }  
}

A resposta para a pergunta é: depende.

(antes de continuar quero ressaltar que toda vez que me referir a um laço for/foreach, assuma que o mesmo se encontra no contexto de lambda expressions / métodos anônimos que capturam variáveis locais / parâmetros)

Para que você possa enterder o problema melhor é necessário antes entender um pouco sobre closures e a sua relação com o uso de variáveis (locais / parâmetros). Se você precisar refrescar a memória recomendo a leitura deste blog post e também deste outro).

Basicamente ambos os métodos do exemplo (GetFuncs1 e 2) criam lambda expressions as quais em seus corpos referenciam a variável local (i)(linhas 26 e 37); para evitar que a área de memória reservada para tal variável seja reutilizada pela CLR o compilador C# "captura" a variável (você pode utilizar o ILDASM ou ILSpy para verificar o código IL gerado e assim entender melhor este processo) e é aqui que os nossos "problemas" começam.

Observe que eu disse que o compilador "captura" as variáveis, não seus valores no momento da criação das lambda expressions; assim, supondo que tivessemos apenas a chamada ao método GetFuncs1(), o código resultante seria equivalente ao código abaixo (note as linhas marcadas: 20, 25-28 e 30) (o código gerado na realidade é bem diferente mas para nossos propósitos podemos tratá-lo como equivalente):

using System;
using System.Collections.Generic;

class Program
{
 private static void Main(string[] args)
 {
  foreach (var func in GetFuncs1())
  {
   Console.WriteLine("[first] {0}", func());
  }
 }

 private static List<Func<int>> GetFuncs1()
 {
  var fs = new List<Func<int>>();

  for (ret = 0; ret < 3; ret++)
  {
   fs.Add(ret_func);
  }
  return fs;
 }

 private static int ret_func()
 {
  return ret;
 }

 private static int ret;
}
Como vemos, ao invés de criar um método para representar o corpo das lambda expressions em cada iteração do laço, o compilador emitiu um único método estático (ret_func() inserindo referências para o mesmo na lista de funções) que simplesmente retorna o valor do campo ret o qual, por sua vez, é atualizado no laço for!

Agora que você já entende porque a saída do programa foi 3,3,3 restam, pelo menos, duas questões:

  1. Como obter o comportamento desejado, ou seja, que a saída do programa seja 0, 1 e 2 ?
  2. Porque eu disse que a saída do programa "dependia" de algo, e o mais importante, depende do que?
A resposta para a primeira pergunta é sim; (veja o programa abaixo) basta declarar uma variável local dentro do laço for e atribuir a variável "i" para a mesma (linha 20) e, então, retornar o valor desta variável no corpo da lambda expression (linha 21) :
using System;
using System.Collections.Generic;

class Program
{
 private static void Main(string[] args)
 {
  foreach (var func in GetFuncs1())
  {
   Console.WriteLine("[first] {0}", func());
  }
 }

 private static List<Func<int>> GetFuncs1()
 {
  var fs = new List<Func<int>>();

  for (int i = 0; i < 3; i++)
  {
   var capture = i;
   fs.Add(() => capture);
  }
  return fs;
 }
}
Se você executar o programa agora verá que a saída do mesmo é exatamente a esperada; isto ocorre porque, agora, como declaramos uma variável local dentro do laço o compilador irá emitir código equivalente ao código abaixo (efetivamente capturando o valor da variável no momento em que a lambada expression é criada):
using System;
using System.Collections.Generic;

class Program
{
 private static void Main(string[] args)
 {
  foreach (var func in GetFuncs1())
  {
   Console.WriteLine("[first] {0}", func());
  }
 }

 private static List<Func<int>> GetFuncs1()
 {
  var fs = new List<Func<int>>();

  for (int i = 0; i < 3; i++)
  {
   var h = new Holder {value = i};
   fs.Add(h.GetIt);
  }
  return fs;
 }

 class Holder
 {
  public int value;

  public int GetIt()
  {
   return value;
  }
 }
}
Novamente ficou mais simples entender porque este código produz o resultado esperado: em cada iteração do laço o compilador instanciou um objeto para armazenar o valor de "i" naquele momento.

Estou certo de que, de agora em diante, toda vez que você utilizar lambda expressions / métodos anônimos você irá certificar-se de usar a construção compatível com o resultado desejado.

Quanto à segunda questão, se este blog tiver um número razoável de leitores, teremos dois grupos com resultados diferentes: 3,3,3 / 2,2,2 e 3,3,3 / 0,1,2 (que é a saída esperada)!

A diferença nos resultados esta relacionada à versão do compilador C# utilizado.

Veja a imagem abaixo:

A versão 5 do C# mudou o comportamento de variáveis capturadas em laços foreach! A partir desta versão o compilador emite código como se a cada iteração uma nova variável local fosse alocada (o mesmo truque que eu apresentei acima);

Agora eu me questiono porque o comportamento de laços for não foram modificados também. O que posso dizer é que, na minha opinião, esta decisão só introduz confusão. Desenvolvedores iniciantes na linguagem irão, invariavelmente, ser surpreendidos por esta diferença de comportamento.

Caso estes desenvolvedores tenham contato primeiramente com laços for os mesmos ficaram tentando entender porque suas lambdas expressions/métodos anônimos estão observando uma valor atualizado da variável capturada e, então, quando eles entenderem o que esta ocorrendo tenderão a usar o truque de "declarar uma variável local dentro do laço" (inclusive em laços foreach). Por outro lado, caso estes desenvolvedores tenham contato com o laço foreach primeiro, eles correm o risco de em algum momento usar um laço for e introduzir bugs (uma vez que os mesmos assumirão que o valor da variável do laço será capturada).

Há uma discussão sobre o assunto que, ainda que eu compreenda os argumentos, não concordo completamente com os mesmos - partes do meu cérebro ainda acham que esta diferença no comportamento é uma inconsistência gratuíta - mas esta é apenas minha opinião.

Se você estiver interessado em mais detalhes sobre o assunto recomendo a leitura do capítulo 8.8.4 da especificação da linguagem C#.

Finalmente um alerta: se você for portar projetos de uma versão do C# anterior à 5.0 para a versão 5.0 ou mais nova preste atenção na combinação lambda expressions / laços for pois como vimos é possível ocorrer mudanças de comportamento.

O que você acha?

(read this post in english)