Often I see developers debating using String vs. string as if it’s a simple style decision. No different than discussing the position of braces, tabs vs. spaces, etc … A meaningless distinction where there is no right answer, just finding a decision everyone can agree on. The debate between String and string though is not a simple style debate, instead it has the potential to radically change the semantics of a program.

C# 7.2 added the ability to mark a struct declaration as readonly. This has the effect of guaranteeing that no member of the struct can mutate its contents as it ensures every field is marked as readonly. This guarantee is imporant because it allows the compiler to avoid defensive copies of struct values in cases where the underlying location is considered readonly. For example when invoking members of a struct which is stored in a readonly field.

At first glance some customer crash reports look simply impossible. The code in question is so throughly tested or on such a common code path that it simply can’t be broken. If it were broken customers would be breaking your inbox with crash reports.

It seems silly to celebrate features which should have been there from the start. But I can’t help but be excited about adding deterministic build support to the C# and VB compilers. The /deterministic flag causes the compiler to emit the exact same EXE / DLL, byte for byte, when given the same inputs. This is a seemingly minor accomplishment that enables a large number of scenarios around content based caching: build artifact, test results, etc …

Errors are the mechanism by which compilers communicate incorrect program to users. Good error messages educate the user about the issue and ideally tells them how to correct it. This is the optimal situation because it allows users to self correct their code. Bad error messages though typically just state the problem, possibly quite cryptically, without any corrective advice and are little better than the compiler spitting out E_FAIL with a line number.