#nullable — Public Fediverse posts

#CSharp #Nullable, because you really have to emphasize the importance that this is, in fact, not null.

Nullable-аннотации: MaybeNull и NotNullWhen в C#

Привет, Хабр! Сегодня мы рассмотрим nullable-аннотации в C#: как с помощью [MaybeNull] и [NotNullWhen] (плюс родственных атрибутов вроде [MaybeNullWhen] , [NotNullIfNotNull] , [DoesNotReturn] ) формально описывать те самые «ну тут иногда null, а тут точно нет».

https://habr.com/ru/companies/otus/articles/928286/

#c# #nullable #nullableаннотации #nullable_reference_types #SystemDiagnosticsCodeAnalysis #MaybeNull #NotNullWhen #MaybeNullWhen

Was fällt euch auf? Ist das wirklich sinnvoll so?
Diskutiert mal! 👀

Bitte denkt selbst nach und fragt nicht einfach eine KI – eure eigenen Ideen interessieren mich viel mehr!

#CSharp #dotnet #fail #dotnetperle #cleancode #boolLogic #CodeReview #nullable #bug

@badcel @khalidabuhakmeh I guess I'm not fully understanding what #nullable does then, since it clearly does not mean things can't be null, at least not in all contexts.

I did use `where T: notnull` now and the error also goes away. But in my mind, that should be the default when #nullable is enabled.

@mortoray @khalidabuhakmeh I think it is a bit confusing because T could either be a reference type or a value type. Value types having a completely different nullability mechanic which is not at all related to #nullable pragma. If you exclude structure types via : “ where T : class” the warning goes away, too and the class should behave as expected as it does not need to care for structs anymore.

@khalidabuhakmeh But yes, nonetheless, declaring it nonnull does fix the problem.

`class Something<T> where T : notnull`

But I still don't understand why. It seems to go against what `#nullable enable` means.

@khalidabuhakmeh But I have `#nullable enable` on the file, implying all references are non-null unless declared otherwise, like `T?`.

Also, if I mark source as `T? source` then I get errors in my code, implying that it isn't actually nullable, except in this circumstance.

@andrewlock I see you enabled nullable, which is quite a minefield with a source-only package that wants to be able to work not only with nullable on or off, but also in a language where nullable isn't an option.

You end up with stuff like this:

https://github.com/xunit/assert.xunit/blob/309647ac2fc29997937a22afaaeb0a73fb80d14b/CollectionAsserts.cs#L1-L8

https://github.com/xunit/assert.xunit/blob/309647ac2fc29997937a22afaaeb0a73fb80d14b/CollectionAsserts.cs#L457-L472

You can't just "#nullable disable" because the compiler might not support it. So if they enable nullable but forget to "tell you", then you have to turn off a bunch of nullable "violations".

This is super duper extra important.

C# Nullable Reference Types are a compile-time thing, not a runtime thing. "string?" and "string" are both just "string" at runtime.

This means:

- Always guard against your users passing `null` even for types that _shouldn't_ allow it, because it's *not a runtime guarantee*.

- You can't create overloads that differ only on nullability (i.e., Method(string) vs. Method(string?)) because *they're the same type at runtime*.

#dotnet #csharp #nullable #nrt

Hey @jasonbock, excellent walkthrough on source generators in https://www.youtube.com/watch?v=KTsyS3rDUgg.

You don't need to restart VS to observe changes to a source generator in another project. A `dotnet build-server shutdown` at the command line resets the build-server cache and forces the generators to re-run from scratch.

Wrt. to nullable, I typically wrap generated code in `#nullable annotation`/`#nullable restore`. Then I do not have to use the damn-it operator.

@anthony_steele for DTO's I'll take a "#nullable disable"

for #dotnet people, when we have #nullable checking on, how do you feel about DTO fields initialised to " = null!;"
e.g.

public string Name { get; set; } = null!;

It seems wrong to me "Name is not nullable, and also, surprise, it's null!"

It seems like that could go wrong.
But if it's the accepted idiom than I'll go with it.

Is there a better one?
"= string.Empty;" is verbose.

What do you think?

@khalidabuhakmeh like with "#nullable disable" or in VB.net "option strict" and "option explicit".

Maybe not that controversial take, but I love the nullable feature in C#. There are occasional situations where the nullable warning appears and I'm like "why???" But all in all, it has been a great help, and has generally made me a better programmer, even when doing stuff with .NET Framework.

#dotnet #csharp #nullable #coding

#CSharpForMarkup 2 for #WinUI3 and @unoplatform is coming along nicely🙂

-🔥Windows C# #hotreload updates UI on Ctrl+S
- All #dotnet 7 target platforms, #csharp 11
- Nested view files in sln explorer
- Fully #nullable + #editorconfig enabled dotnet new template

Is there a recommended pattern to follow when dealing with #nullable types in #TypeScript ?

This snippet is just from the #supabase #nextjs quickstart guide. Since data maybe null when fetched from the Supabase bucket, TS complains since createObjectURL requires the parameter.

I know that I could guard the line with an "if" statement but that just seems unnecessary. Like there should be a more elegant solution, something like optional chaining. :thinking: :javascript: :react:

RT @[email protected]

New null policy: whenever I get a NullReferenceException, I put

#nullable enable

at the top of the file and enable warnings as errors. C#’s progressive inclusion of null reference checking is a life savor on old projects.

🐦🔗: https://twitter.com/praeclarum/status/1161830903556915200