C# Lowering

[giscus[bot]]

C# Lowering

Did you ever hear the word "compiler magic" or "syntactic sugar"? Probably yes and therefore we want to dissect what this "magic" really is!
We can see how we can predict performance or bugs by "lowering" our code. Also we will see how things like foreach, var, lock, using, async, await, yield, anonymous types, record, stackalloc, pattern matching, Blazor components, deconstructor, extension methods... do not really exist.

https://steven-giesel.com/blogPost/69dc05d1-9c8a-4002-9d0a-faf4d2375bce

[mrjohnsonit]

Curious where the term 'Lowering' came from? If Syntactic Sugar == Lowering why rebrand?

[naine]

"Syntactic Sugar" is a more general term to describe language features that don't enable you to do anything you can't do without them, just allowing you to do things in a cleaner way with less code. "Lowering" is an implementation technique within the compiler that involves transforming the code internally before compiling it. Syntactic sugar features aren't necessarily implemented using a lowering (but often are).

[linkdotnet]

Very fair point and absolutely right!

[MSBassSinger]

"Syntactic Sugar" is a more general term to describe language features that don't enable you to do anything you can't do without them, just allowing you to do things in a cleaner way with less code. "Lowering" is an implementation technique within the compiler that involves transforming the code internally before compiling it. Syntactic sugar features aren't necessarily implemented using a lowering (but often are).

Two ways of saying the same thing. "Lowering" is just a made up term, albeit an inaccurate one, for doing things the hard way. In most cases, there is no demonstrable advantage in taking the Luddite approach. If it compiles to the same IL, all you succeeded in doing is making your C# code harder to read.

[naine]

I think you're confusing coding style with the inner workings of the compiler. Lowered code is not meant to be readable, it's internal to the compiler. It also doesn't exactly apply to C# code, since it's applied to the parsed syntax tree.

And lowering is not a made up term, but it's a compiler concept not a programming concept.

[MSBassSinger]

I think you're confusing coding style with the inner workings of the compiler. Lowered code is not meant to be readable, it's internal to the compiler. It also doesn't exactly apply to C# code, since it's applied to the parsed syntax tree.

And lowering is not a made up term, but it's a compiler concept not a programming concept.

No, not confusing anything. "Lowering" has relevance at the compiler level. In reading the comments, some readers seem to find value in applying the concept in their C# code, which is the point I was addressing. Those coming from a Java background would be tempted to go down that rabbit hole.

Thus, at the C# coding level, it is a made-up term to describe the opposite of syntactic sugar, and poor coding practice when used without providing a net positive value.

For the reader who may want more information on lowering in the compiler:

https://mattwarren.org/2017/05/25/Lowering-in-the-C-Compiler/

https://shiver.github.io/post/csharp-lowering/

https://subscription.packtpub.com/book/application-development/9781787286832/9/ch09lvl1sec66/implementing-lowering-code-generation-support-for-a-new-c-language-feature

[ltcmelo]

Here's a library that rewrites certain C# constructs: https://github.com/ShiftLeftSecurity/SharpSyntaxRewriter

[linkdotnet]

Thanks for the reference! it really looks interesting. What was your initial spark to start this @ltcmelo ?

[ltcmelo]

For certain constructs, it's more convenient to implement an static analysis if they are in lowered/desugared form.

[MSBassSinger]

I highly recommend knowing what the IL looks like for various spoonfuls of syntactic sugar.

For example, I do that, and that is why I do not use "using", but use try-catch-finally, which gives better exception control and does not swallow the using object's constructor exception.

But, if the syntactic sugar and the "lowering" process yield the same IL, then just use the syntactic sugar, as there is no advantage to "lowering".

[smurthys]

I do not use "using", but use try-catch-finally, which gives better exception control and does not swallow the using object's constructor exception.

Good point. For exactly the reason you specify, using is syntactic sugar only for a specific pattern of using try-catch-finally. I'd use it regardless of whether it is "lowered" if I need that exact semantics, just to improve readability.

[fmargueirat]

I'm wondering why is the array copied in the 2nd example? Is that to ignore changes that may be done in the original array in multi-threading code?

[linkdotnet]

Good question, I wanted to expand the article about that topic, but I am not 100% sure (but roughly 90%).

My educated guess is that the int[] array2 = array part is to be thread-safe. Keep in mind that foreach is a very general construct that can be used everywhere.
There is a chance that while you enumerate through your enumeration, the pointer may change (because of a second thread that runs in parallel). If you copy the pointer beforehand, your foreach is safe against that.

[naine]

The language rules dictate that the expression in the foreach statement is evaluated exactly once. Imagine if you had foreach (var x in GetArray()), the method must be called exactly once with the returned array reference assigned to a temporary variable. Even if the expression is a simple local variable reference (being a local, it is not accessible by other threads), it is possible to reassign the variable within the loop, but the loop must continue over the array it referred to when entering the loop, hence the compiler must copy the array reference to a temporary. Of course the compiler could optimize out the temporary in the specific example shown, but this would complicate the implementation so it leaves the optimization to the JIT.

[linkdotnet]

Thanks for the input - I will update that passage (and, of course giving credits you).

[Caltor]

Why is everyone so obsessed about syntactic sugar? All control structures beyond if and while are syntactic sugar. You could write every program in them. That is the essence of turing completeness.

[toupswork]

How is stackalloc syntactic sugar?

[linkdotnet]

I understand the need for such hot paths, but I would argue that they should be evaluated case by case. In the majority of cases, boxing/unboxing will not make any difference (also mainly because the majority of DTO's are classes).
Also given the lambdas ThenAdd(() => ...) can create GC pressure and lead to subtle bugs and long-living objects one did not intend.

Often, you will go much further if you optimize other levels before asking yourself whether or not something gets boxed. Again that really depends on the concrete situation/application/scenario.

[toupswork]

The JIT can optimize boxing in simple scenarios, not something like this. And to your point about lambdas, I know better than to create a closure, so that's not an issue

[toupswork]

Also, everywhere I've worked, repos and API clients don't just return a DTO; they return a result object. And those result types are often value types like what I have.

[linkdotnet]

That makes sense and that is why I said, that it has to be justified case by case.

In the average case of my projects complex DTO's were always classes (if it wasn't a bool, int and so on).
The ServiceResult I saw until now was also always a class.

[toupswork]

I have benchmarks that show it's faster with a struct, even with value copying. Besides the memory overhead of the method table, Sync Block, padding alignment, and garbage collection just to create a small class with two fields, the JIT can pass the value type through registers rather than pushing it onto the stack.