One request I see fairly often for C# is to add the concept of borrowed values. That is values which can be used but not stored beyond the invocation of a particular method. This generally comes up in the context of features which require a form of ownership semantics like stack allocation of classes, using statements, resource management, etc … Borrowing provides a way to safely use owned values without complicated ownership transfer.

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 …