C# Lowering

Pedro Drewanz — Sat, 29 Mar 2025 21:54:10 +0000

O processo de compilação

Você sabe como é o processo que seu código em C# passa para ser executado?
Muita se fala sobre o processo de compilar o código, que transforma o código C# em IL, mas existe um passo anterior que transforma C# em ... C#.

Esse processo é conhecido como Lowering.

Ele é responsável por um processo que vai "otimizar" o código para o compilador e vai trocar algumas facilidades da linguagem por comandos que são entendidos mais facilmente pelo compilador.
Isso tem ajudado muito na adição de funcionalidades no C#, como é o caso do record ou até mesmo como agora são permitidos top-level statements.

Exemplos de Lowering

O record é utilizado para representar um objeto de valores imutáveis.
Porém isso já poderia ser feito usando classes com parâmetros no construtor e propriedades readonly.
O que o record faz é facilitar essa implementação comum para o desenvolvedor.

Por exemplo, quando você escreve:

public record Record(int ID);

O que o compilador vai receber é:


[NullableContext(1)]
[Nullable(0)]
public class Record : IEquatable<Record>
{
    [CompilerGenerated]
    [DebuggerBrowsable(DebuggerBrowsableState.Never)]
    private readonly int <ID>k__BackingField;

    [CompilerGenerated]
    protected virtual Type EqualityContract
    {
        [CompilerGenerated]
        get
        {
            return typeof(Record);
        }
    }

    public int ID
    {
        [CompilerGenerated]
        get
        {
            return <ID>k__BackingField;
        }
        [CompilerGenerated]
        init
        {
            <ID>k__BackingField = value;
        }
    }

    public Record(int ID)
    {
        <ID>k__BackingField = ID;
        base..ctor();
    }

    [CompilerGenerated]
    public override string ToString()
    {
        StringBuilder stringBuilder = new StringBuilder();
        stringBuilder.Append("Record");
        stringBuilder.Append(" { ");
        if (PrintMembers(stringBuilder))
        {
            stringBuilder.Append(' ');
        }
        stringBuilder.Append('}');
        return stringBuilder.ToString();
    }

    [CompilerGenerated]
    protected virtual bool PrintMembers(StringBuilder builder)
    {
        RuntimeHelpers.EnsureSufficientExecutionStack();
        builder.Append("ID = ");
        builder.Append(ID.ToString());
        return true;
    }

    [NullableContext(2)]
    [CompilerGenerated]
    public static bool operator !=(Record left, Record right)
    {
        return !(left == right);
    }

    [NullableContext(2)]
    [CompilerGenerated]
    public static bool operator ==(Record left, Record right)
    {
        return (object)left == right || ((object)left != null && left.Equals(right));
    }

    [CompilerGenerated]
    public override int GetHashCode()
    {
        return EqualityComparer<Type>.Default.GetHashCode(EqualityContract) * -1521134295 + EqualityComparer<int>.Default.GetHashCode(<ID>k__BackingField);
    }

    [NullableContext(2)]
    [CompilerGenerated]
    public override bool Equals(object obj)
    {
        return Equals(obj as Record);
    }

    [NullableContext(2)]
    [CompilerGenerated]
    public virtual bool Equals(Record other)
    {
        return (object)this == other || ((object)other != null && EqualityContract == other.EqualityContract && EqualityComparer<int>.Default.Equals(<ID>k__BackingField, other.<ID>k__BackingField));
    }

    [CompilerGenerated]
    public virtual Record <Clone>$()
    {
        return new Record(this);
    }

    [CompilerGenerated]
    protected Record(Record original)
    {
        <ID>k__BackingField = original.<ID>k__BackingField;
    }

    [CompilerGenerated]
    public void Deconstruct(out int ID)
    {
        ID = this.ID;
    }
}

Muito mais complexo, não é?

Outro exemplo, que está na linguagem tem um bom tempo é o uso de foreach:

Record[] records = [new Record(1), new Record(2), new Record(3)];

foreach (var x in records)
{ 
    Console.WriteLine(x.ID);
}

Se torna:

private static void <Main>$(string[] args)
{
    Record[] array = new Record[3];
    array[0] = new Record(1);
    array[1] = new Record(2);
    array[2] = new Record(3);
    Record[] array2 = array;
    Record[] array3 = array2;
    int num = 0;
    while (num < array3.Length)
    {
        Record record = array3[num];
        Console.WriteLine(record.ID);
        num++;
    }
}

No exemplo ainda conseguimos ver como a inicialização de listas, que foi adicionada mais recentemente, funciona por trás dos panos.

Outro ponto importante é que nesse caso podemos ver a diferença de código gerado quando se usa tipos diferentes.
O mesmo código anterior, usando List ao invés de Array gera a seguinte saída:

int num = 3;
List<Record> list = new List<Record>(num);
CollectionsMarshal.SetCount(list, num);
Span<Record> span = CollectionsMarshal.AsSpan(list);
int num2 = 0;
span[num2] = new Record(1);
num2++;
span[num2] = new Record(2);
num2++;
span[num2] = new Record(3);
num2++;
List<Record> list2 = list;
List<Record>.Enumerator enumerator = list2.GetEnumerator();
try
{
    while (enumerator.MoveNext())
    {
        Record current = enumerator.Current;
        Console.WriteLine(current.ID);
    }
}
finally
{
    ((IDisposable)enumerator).Dispose();
}

Tudo isso permitiu que várias facilitações e funcionalidades fossem feitas na linguagem ao longo dos anos, sem alterações muito significativas no compilador. Acredito que uma das maiores foi o acréscimo de async/await na linguagem, que facilitou muito a programação assíncrona em comparação com o modelo anterior.

Além dessas facilidades de escrita e funcionalidades, também são implementadas melhorias de performance. Saber que esse processo existe, e como ver o código gerado por ele, pode facilitar o nosso entendimento de alguns comportamentos que nosso código exibe, como podemos ver a seguir.

Comportamentos inesperados

O que me motivou esse post foi encontrar recentemente um comportamento inesperado em um método extremamente simples e que foi compreendido com mais facilidade através da análise do código gerado pelo lowering.

Vamos levar a seguinte classe em consideração:

public class Example
{
   public double ValueA {get;set;}
   public int ValueB {get;set;}

   public object GetByIndex(int index)
     => index switch
     {
        0 => ValueA,
        1 => ValueB,
        _ => throw new Exception("")         
     };
}

Essa implementação foi necessária por conta de um tipo de serialização que leva em consideração a ordem dos campos, e foi levemente alterada para simplificar o exemplo.

Como esse código é usado por uma biblioteca de serialização o tipo do valor retornado é bem importante (mesmo que esteja sofrendo boxing pelo tipo de retorno ser object).

Agora a dúvida.
Caso o seguinte código seja executado, o que será exibido no console?

var example = new Example
{
    ValueA = 2.0,
    ValueB = 50
};

Console.WriteLine(example.GetByIndex(0).GetType().FullName);
Console.WriteLine(example.GetByIndex(1).GetType().FullName);

Se você espera que seja

System.Double
System.Int32

Eu e você estamos no mesmo barco.
Porém no barco errado....
O que é exibido é:

System.Double
System.Double

Agora vamos entender porque isso acontece, olhando o código gerado após o lowering para o método GetByIndex:

[NullableContext(1)]
public object GetByIndex(int index)
{
    double num;
    if (index != 0)
    {
        if (index != 1)
        {
            throw new Exception("");
        }
        num = ValueB;
    }
    else
    {
        num = ValueA;
    }
    return num;
}

Olhando esse código fica claro o motivo de o valor retornado está com o tipo double, agora falta entender o porquê.
Primeiro vamos olhar outros cenários para entender quando isso acontece e quando não acontece.
Quando usamos um switch...case ao invés de um switch expression o resultado é o esperado.

Antes do lowering:

 public object GetByIndex(int index)
{
    switch(index)
    {
        case 0: return ValueA;
        case 1: return ValueB;
        default: throw new Exception("");
    }
}

Após lowering:


[NullableContext(1)]
public object GetByIndex(int index)
{
    if (index != 0)
    {
        if (index == 1)
        {
            return ValueB;
        }
        throw new Exception("");
    }
    return ValueA;
}

O problema também não acontece caso os tipos das propriedades sejam double e decimal:

public class Example
{
   public double ValueA {get;set;}
   public decimal ValueB {get;set;}

   public object GetByIndex(int index)
     => index switch
     {
        0 => ValueA,
        1 => ValueB,
        _ => throw new Exception("")         
    };
}

Após o lowering:

[NullableContext(1)]
public object GetByIndex(int index)
{
    if (index != 0)
    {
        if (index == 1)
        {
            return ValueB;
        }
        throw new Exception("");
    }
    return ValueA;
}

Então o que acarreta na resultado inesperado?

Se olharmos o switch expression inicial, fora do contexto de implementação do método, fica um pouco mais fácil de entender.

int index = 1; 
var result = index switch
     {
        0 => 2.0,
        1 => 1,
        _ => throw new Exception("")         
     };

Como podemos ver, o resultado da switch expression deve ser atribuído a uma variável e para isso o compilador escolhe um tipo em comum entre os retornos de todos as opções existentes. Como qualquer valor do tipo int pode ser representado no tipo double, o valor inteiro é convertido para double.
Caso adicionemos uma nova opção 2 => "outro valor", então o único tipo em comum entre as três opções é object. Desse modo os três valores vão sofrer boxing, e mantêm o tipo original de alguma forma.

O que posso fazer?

Conhecer a existência do processo de lowering e como ele se encaixa como etapa do processo de compilação nos ajuda a ter uma caixa de ferramentas maior na hora de entender e solucionar problemas.

Quer ver como partes do seu código está ficando após o lowering? Pode acessar aqui e ver: https://sharplab.io/

Além disso, se quiser ver um pouco mais:

DEV Community: Pedro Drewanz

C# Lowering

O processo de compilação

Exemplos de Lowering

Comportamentos inesperados

O que posso fazer?