Errata

The last code presented in the page is not equivalent to the previous code because of the change of the coordinate's types from double to int. The correct must be:

record Point (double X, double Y);

instead of:

record Point(int X, int Y);

Platform support for macOS stated: web and command line applications. However, VS for Mac creates rich-client applications just fine using either Xamarin or GTK#. This looks like a minor technical error, but it may have huge impact on a person assessing C#.

The list of contextual keywords was not updated with the new C# 9 contextual keywords. The following new contextual keywords are missing:
init
managed
nint
notnull
nuint

Another mistake is that the keyword "in" is classified as contextual keyword, but it is a keyword. In the book, the "in" keyword appears in both lists: keywords, and contextual keywords.

The explanation cite a "Test" class that doesn't exist anymore, like in the previous version of the book: "C# 8.0 in a Nutshell". This is because the author moved the code inside the "Main" static method in the "Test" class to outside using the new top-level statements introduced in C# 9.0.

"Because the CLR doesn't explicitly support top-level statements, the compiler translates your code into something like this:

using System;

static class Program$ // Special compiler-generated name
{
static void Main$() // Soecial compiler-generated name
{
...

With tools like .NET assembly browser and decompiler "ILSpy 7.0+", the author can view exactly how the compiler translates the code as follow:

using System;
using System.Runtime.CompilerServices;

[CompilerGenerated]
internal static class <Program>$
{
private static void <Main>$(string[] args)
{
...

It is important to note that the array of strings "args" is declared as a parameter in the "Main" method by the compiler and can be accessed in top-level statements.

The first data row of the table, for integral-signed numeric types, shows "sbyte" as the "System type" of the "sbyte" C# type. The correct must be "SByte", once the type use pascal case and C# is case-sensitive.

Follow the text fragment with a mistake in the code:
"Without the F suffix, the following line would not compile, because 4.5 would be inferred to be of type double, which has no implicit conversion to float:

float f = 4.5F;"

The code is correct and will compile successfully. According to text description, the wrong code must be:

float f = 4.5;

In this case, the literal 4.5 will be of the type "double" and cannot be implicitly converted to float, causing the following compile-time error:
"error CS0664: Literal of type double cannot be implicitly converted to type 'float'; use an 'F' suffix to create a literal of this type"

The following text fragment contains a mathematical mistake:
"Division operations on integral types always truncate remainders (round toward zero)."

The correct must be:
A division operation on integral types truncate the quotient.

The following text and code are not 100% precise:
"You cam implicitly convert between them:

nint x = 123;
IntPtr p = x;
nint y = p;"

As the book author explains, the types nint and nuint are represented by underlying types System.IntPtr and System.UIntPtr, respectively, but with compiler surfacing additional conversions and operations for those types as native ints.

In the subtopic "Conversions" of the topic "Native-sized integers" of the "C# 9.0 specification proposal", we have the following explanation:
"There is an identity conversion between nint and IntPtr, and between nuint and UIntPtr."

Notice the use of "identity conversion" instead of "implicit conversion", because this is a very special case supported by the compiler. Implicit conversion is not appropriated because there is no implicit operator implementation to support implicit conversion.

1. The following contextual keywords are missing from the list:
init.nint,nuint,notnull.
2. The in keyword appears both as a keyword and as a contextul keyword.
3. C# official web page lists the record keyword as a regular keyword, not as a contextual keyword.

The following last code of the topic "String interpolation" will not behave like desired:

int x = 2;
// Note that $ must appear before @ prior to C# 8:
string s = $@"this spans {
x} lines";

The CR-LF character was positioned inside the braces that delimit the interpolation expression, in this case: the x value. Once the interpolation expression inside the braces is evaluated to 2, the CR-LF is lost and the s string will contain a string with only one line.

To correct the code, you must put the CR-LF outside the braces, as the following example possible code:

int x = 2;
// Note that $ must appear before @ prior to C# 8:
string s = $@"this spans
{x} lines";

Now, the code produces the following string:
"this spans
2 lines"

The table of default values omit the following two categories of types:

Type: All nullable value types
Default value: null (the nullable value type instance will have the "HasValue" property with value false, and the attempt to read the "Value" property will throw the "InvalidOperationException" with the message: "Nullable object must have a value.")

Type: struct
Default value: The value produced by setting all struct fields to their default values.

Following the authors table of parameter modifiers, the table can be modified for more accuracy:
-----------------------------------------------------------------------------------------------
Modifier | Passed by | Variable must be definitely assigned
-----------------------------------------------------------------------------------------------
(None) | Value | Going in
ref | Reference | Going in and out
in | Reference (read-only) | Going in
out | Reference (write-only) | Going out
-----------------------------------------------------------------------------------------------

Author's book explanation:
"To do the converse (pass a default value to x and an explicit value to y), you must combine optional parameters with named arguments."

The use of named arguments is a possible solution, as the following code:
Foo(y: 1); // 0, 1

But, it isn't the only solution as the use of "must" suggests. For example, there is another possible solution with the use of the keyword "default", as the following code:
Foo(default, 1); // 0, 1

The operator name "Unsafe stack allocation" for "stackalloc" operator is now inappropriate. Starting with C# 7,2, you don't have to use an unsafe context when you assign a stack allocated memory block to a Span<T> or ReadOnlySpan<T> variable.

The "Table 2-3" lists C# operators categories in order of precedence. According to the "C# language reference", the "sizeof" operator is in the category "Primary" instead of "Unary", like the book's table. In this context, the book's table is classifying the "sizeof" operator with a lowest precedence in comparison with the "C# language reference". "sizeof" must be classified in the "Primary" category.

The category "Relational" must be "Relational and type-testing" because the operators <, >, <=, and >= are relational, and the operators "is" and "as" are type-testing.

Follow a fragment of the first paragraph of the topic "Declaration Statements" on page 76 of the book:
"A declaration statement declares a new variable, optionally initializing the variable with an expression."

The explanation above is of "variable declaration", that is one of two possible declaration statements: variable declaration or constant declaration. The paragraph above must be corrected to:
"A variable declaration declares a new variable, optionally initializing the variable with an expression."

The book's author classify "throw" as a jump statements with "break", "continue", "goto", and "return".

According to the "C# language reference", the "jump statements" are only: break, continue, goto, and return. throw is classified as one of the "Exception Handling Statements".

The book's author ends the note with the following text:
"A good example is the TextBox class, which is defined both in System.Windows.Controls (WPF) and System.Windows.Forms.Controls (Windows Forms)."

The namespace System.Windows.Forms.Controls doesn't exist in the Windows Forms Framework. The correct namespace in Windows Forms that the TextBox class belongs to is System.Windows.Forms, without ending with Controls. The full qualified name of the TextBox class in Windows Forms is System.Windows.Forms.TextBox.

Follow the paragraph content:
"The derived classes, Stock and House, inherit the 'Name' property from the base class, Asset."

'In the example code, the member 'Name' is declared as a public field instead of a public property.

The codes in approaches #1 and# 2 don't compile because the field 'SharesOwned' of the class 'Stock' is declared as 'long', and 'long' cannot be implicitly converted to "int". The code could be modified as follow:

long shares = ((Stock)a).SharesOwned; // Approach #1
long shares = (a as Stock).SharesOwned; // Approach #2

Considering the statement "The Contains method doesn’t offer the convenience of this overload, although you
can achieve the same result with the IndexOf method." C# 10 does have this overload and this is possible => "abcdef".Contains("aBc", StringComparison.InvariantCultureIgnoreCase)

You say in the WeakReference Delegate example that:

where TDelegate : Delegate //Compiler doesn't allow this


This is not true anymore. Since C# 7.3 type constraints can deal with Enum and Delegate constraints. I assume this also has influence in other parts of the book.