right, c#'s nullable types are the ultimate in syntactic sugar in that you can just use them like regular value types in most places without realizing they are monads underneath.
I wouldn't say they have substantially more syntactic sugar than other languages with the same. If you need to use them in the context that is not optional, you need to use HasValue/Value, or casts, or (since recent versions) pattern matching to extract the value.
The only special sauce I can think of is that C# also implements null-lifting for most operators in the language, which is not necessarily a good thing because it treats null as "unknown" rather than "missing" - e.g. a + b works on int?, and will produce null if either a or b is null. With Boolean operators, it's even clearer - false & null is false, true | null is true, but true & null is null, and false | null is null. But quite often this is not what I actually want! If null really means that the value is missing, then a + b shouldn't even compile for optionals. But in practice, I'd say that vast majority of all uses of Nullable are to denote missing rather than indeterminate values.
The only special sauce I can think of is that C# also implements null-lifting for most operators in the language, which is not necessarily a good thing because it treats null as "unknown" rather than "missing" - e.g. a + b works on int?, and will produce null if either a or b is null. With Boolean operators, it's even clearer - false & null is false, true | null is true, but true & null is null, and false | null is null. But quite often this is not what I actually want! If null really means that the value is missing, then a + b shouldn't even compile for optionals. But in practice, I'd say that vast majority of all uses of Nullable are to denote missing rather than indeterminate values.