W C# przecież jest nullable
po co komplikować projekt jakimiś bibliotekami?
nullable
jest przecież całkowitą odwrotnością optionala, pozwala na używanie null
tam, gdzie go miało nie być, zamiast zwracania pustej wartości.
Co to znaczy "nie działa"? Oczywiście, że może i widać to przecież na moim screenie, że VS informuje o tym. Jeśli chcesz poinformować siebie, że ta lista może przyjąć null to robisz List? list
, wtedy VS ci "podkreśli" jak będziesz chciał zrobić list.Where()
albo inne linq. To nie ma zablokować kompilacji, bo kod jest poprawny przecież. To problem programisty, czy to obsłuży, czy nie.
Tyle, że języki powinny zmniejszać liczbę problemów programisty, a nie ją zwiększać.
Zaznaczam, że wątek jest o przypisaniu śmiesznego Option
z zewnętrzenej biblioteki, aby nulla nie było, a to się kompletnie niczym nie różni od przypisania temu obiektowi domyślnej wartości bez biblioteki już pomijając, czy nullable w C# ma sens, czy nie
Ale jaką domyślna wartością? null
to nie jest żadna wartość, to jest brak referencji.
Różnica taka jak między trzymaniem w ręce pustego portfela, a brakiem ręki.
Z bardziej pragmatycznego punktu widzenia - nie pozwala na modelowanie silnie typowanego i spójnego przepływu danych, trzeba ifować kod jak zwierzęta programiści C.
To pokaż mi jak przypisujesz null
do takiego typu mając <Nullable>enable</Nullable>
i <WarningsAsErrors>Nullable</WarningsAsErrors>
.
Pomijając jakieś cuda z refleksją żeby celowo popsuć kod.
Proszę bardzo:
string s = null!;
Fajne te wszystkie nullowe errory, szkoda, że wystarczy jeden wykrzyknik, aby je wyłączyć. Zwłaszcza w takim kontekście to wygląda absurdalnie.
Do tego włączenie tych opcji broni nas jedynie w ramach własnego kodu. W przypadku jakichkolwiek interakcji z zewnętrznymi bibliotekami, są duże szanse, żenull
i tak przyjdzie, więc trzeba się przed nim zabezpieczyć, więc zysk taki, że mamy może 20% nullowej ifologi mniej.
Odpowiadając na pytanie - nie, nie używam tych monad, bo nie widzę ich sensu, stosuję Result<T>
i Null Object Pattern.