Nowe słowo kluczowe field w C# 14

Konfiguracja: Prosty model osoby

[0:12 - 1:07] Tim zaczyna od aplikacji konsolowej dzialajacej na .NET 10 i Visual Studio 2026. Demo koncentruje sie na klasie Person z kilkoma wlasciwosciami:

public required string FirstName { get; set; }
public required string LastName { get; set; }
public int Age { get; set; }

public required string FirstName { get; set; }
public required string LastName { get; set; }
public int Age { get; set; }

Jest rowniez wlasciwosc Demo wspierana przez prywatne pole, ktore staje sie istotne, gdy pojawia sie konflikt nazewnictwa. W Program.cs, Tim tworzy instancje z FirstName = "Tim" i LastName = "Corey", nastepnie drukuje nazwisko, wiek i wartosc demo. Wszystko wyświetla się zgodnie z oczekiwaniami: "Corey", 0 (domyślny integer) i "test".

Problem: Auto-właściwości akceptują błędne dane

[1:23 - 2:49] Problem pojawia sie, gdy Tim przypisuje null do LastName po konstrukcji:

p.LastName = null;

p.LastName = null;

Chociaz LastName jest oznaczone jako required i napisane jako nie-nullowalny ciag znakow, przypisanie kompiluje sie. Modyfikator required jedynie wymaga podania wartosci podczas inicjalizacji obiektu; nie zapobiega temu, aby ktos pozniej ustawil wlasciwosc na null. Wynikiem jest pusta nazwa podczas wykonywania bez rzucania błędu.

To prawdziwa luka w integralności danych. System typu ostrzega cię za pomocą nullable reference squiggle, ale to tylko podpowiedź w czasie kompilacji, nie ochrona w czasie wykonywania. Jesli twoja aplikacja zalezy od tego, ze LastName zawsze zawiera wazny ciag znakow, tylko wlasciwosci automatyczne nie moga tego wymusic.

Stare rozwiązanie: Pełne właściwości z ręcznymi polami pomocniczymi

[2:58 - 4:19] Przed C# 14 standardowym rozwiązaniem było przekształcenie auto-właściwości w pełną właściwość z explicite pole pomocnicze:

private string _lastName;
public required string LastName
{
    get => _lastName;
    set => _lastName = value ?? throw new ArgumentNullException(nameof(LastName));
}

private string _lastName;
public required string LastName
{
    get => _lastName;
    set => _lastName = value ?? throw new ArgumentNullException(nameof(LastName));
}

Tim uruchamia to i potwierdza, że wyjątek uruchamia się poprawnie: "Wartość nie może być null. Nazwa parametru: LastName." Podejście działa, ale wymaga zadeklarowania prywatnego pola, połączenia zarówno gettera, jak i settera oraz powtórzenia nazwy właściwości na kilku liniach. Dla jednej reguły walidacji to dużo ceremonii.

Getter w tym przypadku nie robi nic szczególnego; zwraca niezmienione pole. Mimo to musisz je napisać explicite, ponieważ składnia wymaga obu połówek po opuszczeniu auto-właściwości. Tim ujęcia tę rozwlekłość jako motywację dla nowej funkcji.

Rozwiązanie C# 14: Słowo Kluczowe field

[4:23 - 5:47] C# 14 wprowadza środkową drogę. Zamiast deklarowac prywatne pole zaplecza samodzielnie, mozesz uzyc kontekstowego slowa kluczowego field wewnatrz getter lub setter, aby odwolywac sie bezposrednio do pola zaplecza generowanego przez kompilator:

public required string LastName
{
    get;
    set => field = value ?? throw new ArgumentNullException(nameof(LastName));
}

public required string LastName
{
    get;
    set => field = value ?? throw new ArgumentNullException(nameof(LastName));
}

Getter pozostaje automatycznie zaimplementowanym get; bez wymaganej tresci. Setter uzywa field, aby przypisac przychodzacy value po walidacji. Kompilator tworzy i zarządza polem pomocniczym w tle, tak jak to robi ze standardową auto-właściwością.

Uruchomienie demonstracji przynosi ten sam ArgumentNullException podczas przypisania nul. Zachowanie jest identyczne z wersją ręcznie wspieraną, skompresowaną z siedmiu linijek na zwięzły blok, który dostosowuje tylko to, co wymaga dostosowania. Zachowujesz auto-właściwość gettera, dodajesz logikę tylko do settera i pomijasz ręczne deklarowanie pola całkowicie.

Daje to użyteczną środkową opcję między czystą auto-właściwością (jedna linia, brak walidacji) a pełną właściwością (siedem lub więcej linii, pełna kontrola). Kiedy twoja logika dotyka tylko settera, nie płacisz syntaktycznego kosztu przepisywania także gettera.

Walidacja wieku za pomocą blokady Settera

[6:16 - 7:39] Aby pokazac, ze field nie jest ograniczone do sprawdzania pustych wartosci, Tim dodaje walidacje zakresu do wlasciwosci Age property:

public int Age
{
    get;
    set
    {
        if (value > 0 && value < 120)
            field = value;
    }
}

public int Age
{
    get;
    set
    {
        if (value > 0 && value < 120)
            field = value;
    }
}

Tutaj setter cicho ignoruje wartości poza rozsądnym zakresem. Przypisanie -5 pozostawia Age w domyslnym stanie zero, poniewaz warunek nie zostal spelniony i field nigdy nie zostaje napisane. Tim zauwaza, ze moznaby wyrzucic wyjatek zamiast tego, ale bezglosne podejscie demonstruje, ze cialo settera moze zawierac dowolna logike, jaka potrzebujesz, wciaz polegajac na field dla przechowywania.

Wzór ma szerokie zastosowanie: przymierzanie zakresów numerycznych, przycinanie spacji z ciągów, normalizowanie wielkości liter lub dowolna transformacja, którą chcesz zastosować za każdym razem, gdy właściwość jest ustawiana.

Konflikty nazwowości z istniejącymi zmiennymi field

[7:39 - 9:43] Tim wprowadza celowy przypadek brzegowy. Klasa demo ma prywatnego czlonka doslownie nazwanego field:

private string field = "test";

private string field = "test";

Gdy C# 14 jest aktywne, kompilator traktuje field wewnatrz akcesora wlasciwosci jako slowo kluczowe, a nie zmienną. To oznacza, ze wlasciwosc odnoszaca sie do field w ciszy odczytuje z ukrytego magazynu za wlasciwoscia (ktory jest pusty) zamiast z czlonka ciagu zawierajacego "test". Wyjście zmienia się na puste bez błędu kompilacji, tylko z ostrzeżeniem.

Istnieja dwa obejscia. Prefiksowanie this.field mowi kompilatorowi, ze chodzi o czlonka na poziomie klasy, a nie o slowo kluczowe. Alternatywnie, ucieczka @field dziala w ten sam sposob:

// Both refer to the instance variable, not the keyword
string demo => this.field;
string demo => @field;

// Both refer to the instance variable, not the keyword
string demo => this.field;
string demo => @field;

Silna rekomendacja Tima to zmiana nazw kazdej zmiennej nazwanej field podczas aktualizacji do C# 14. Szybkie "Zmien nazwe dla wszystkich" w IDE usuwa zagadzke na stale. Konflikt występuje tylko wewnątrz akcesorów właściwości; konstruktory i metody rozwiazuja field do nazwy zmiennej zgodnie z oczekiwaniami, poniewaz te konteksty nie maja implicitnego magazynu zaplecza.

Zakończenie: Mniej szablonu, ta sama kontrola

[10:04 - 10:28] Slowiennictwo field wypelnia praktyczna luke w codziennym kodzie C#. Właściwości potrzebujące jednej klauzuli zabezpieczającej lub transformacji nie wymagają już pełnego przepisania z ręcznymi polami pomocniczymi. Dostosowujesz tylko ten akcesor, który wymaga logiki, a drugi pozostaje jako standardowa auto-implementacja.

Wnioski

[10:28 - 10:35] Podsumowujac: slowo kluczowe field C# 14 daje Ci bezposredni dostep do implicitnego magazynu zaplecza wewnatrz jakiegokolwiek akcesora wlasciwosci. Używaj tego do dodania walidacji settera, transformacji gettera lub obu, bez porzucania składni auto-właściwości dla części, które nie wymagają dostosowania.

Przed aktualizacja, przeszukaj swoja baze kodu w poszukiwaniu jakichkolwiek zmiennych nazwanych field i zmien ich nazwy. Ta jedna środa zapobiega jedynemu prawdziwemu "gotcha", którą ta funkcja wprowadza. Poza tym jest to czyste zmniejszenie ilości szablonu, które naturalnie wpisuje się w to, jak większość deweloperów już strukturalizuje swoje modele.

Przyklad porady: Jezeli potrzebujesz jedynie walidacji settera, pozostaw getter jako zwykly get; bez tresci. Kompilator traktuje to jako auto-zrealizowany getter właściwości, a ty unikasz pisania instrukcji return, który nie dodaje niczego.

Obejrzyj pełne wideo na jego kanale YouTube i zdobądź więcej informacji na temat funkcji języka C#.