Dlaczego std :: initializer_list nie jest językiem wbudowanym?

Dlaczego nie std::initializer_listma wbudowanego języka podstawowego?

Wydaje mi się, że jest to dość ważna cecha C ++ 11, a mimo to nie ma własnego zarezerwowanego słowa kluczowego (lub czegoś podobnego).

Zamiast tego initializer_listjest to po prostu klasa szablonu z biblioteki standardowej, która ma specjalne, niejawne mapowanie z nowej składni listy braced-init, {...} która jest obsługiwana przez kompilator.

Na pierwszy rzut oka to rozwiązanie jest dość hakerskie .

Czy w ten sposób będą teraz wdrażane nowe dodatki do języka C ++: przez niejawne role niektórych klas szablonów, a nie przez język rdzenia ?

Rozważ te przykłady:

   widget<int> w = {1,2,3}; //this is how we want to use a class

dlaczego wybrano nową klasę:

   widget( std::initializer_list<T> init )

zamiast używać czegoś podobnego do któregokolwiek z tych pomysłów:

   widget( T[] init, int length )  // (1)
   widget( T... init )             // (2)
   widget( std::vector<T> init )   // (3)

1. klasyczną tablicę, którą prawdopodobnie mógłbyś dodać consttu i tam
2. trzy kropki już istnieją w języku (var-args, teraz variadic templates), dlaczego nie użyć ponownie składni (i sprawić, by wyglądała jak wbudowana )
3. tylko istniejący kontener, można dodać consti&

Wszystkie są już częścią języka. Napisałem tylko swoje 3 pierwsze pomysły, jestem pewien, że istnieje wiele innych podejść.

Były już przykłady "podstawowych" funkcji języka, które zwracały typy zdefiniowane w stdprzestrzeni nazw. typeidpowraca std::type_infoi (być może rozciągając punkt) sizeofpowraca std::size_t.

W pierwszym przypadku musisz już dołączyć standardowy nagłówek, aby używać tej tak zwanej funkcji „języka podstawowego”.

Teraz w przypadku list inicjalizujących zdarza się, że do wygenerowania obiektu nie jest potrzebne słowo kluczowe, składnia to kontekstowe nawiasy klamrowe. Poza tym to to samo co type_info. Osobiście nie sądzę, że brak słowa kluczowego sprawia, że ​​jest to „bardziej hakerskie”. Być może nieco bardziej zaskakujące, ale pamiętaj, że celem było zezwolenie na taką samą składnię inicjalizatora ze wzmocnieniem, która była już dozwolona dla agregacji.

Więc tak, prawdopodobnie możesz spodziewać się więcej tej zasady projektowania w przyszłości:

• jeśli pojawi się więcej okazji, w których możliwe jest wprowadzenie nowych funkcji bez nowych słów kluczowych, komisja je wybierze.
• jeśli nowe funkcje wymagają złożonych typów, wówczas te typy zostaną umieszczone w stdzamiast jako wbudowane.

W związku z tym:

• jeśli nowa funkcja wymaga złożonego typu i może zostać wprowadzona bez nowych słów kluczowych, otrzymasz to, co masz tutaj, czyli składnię „języka podstawowego” bez nowych słów kluczowych i która wykorzystuje typy bibliotek z std.

Myślę, że sprowadza się to do tego, że w C ++ nie ma absolutnego podziału między „językiem podstawowym” a standardowymi bibliotekami. W standardzie są to różne rozdziały, ale każdy z nich odnosi się do siebie nawzajem i zawsze tak było.

W C ++ 11 istnieje inne podejście, polegające na tym, że lambdy wprowadzają obiekty, które mają anonimowe typy generowane przez kompilator. Ponieważ nie mają nazw, w ogóle nie znajdują się w przestrzeni nazw, a już na pewno nie std. Nie jest to jednak odpowiednie podejście do list inicjalizujących, ponieważ używasz nazwy typu podczas pisania konstruktora, który ją akceptuje.

Wydaje się, że Komitet Standardowy C ++ woli nie dodawać nowych słów kluczowych, prawdopodobnie dlatego, że zwiększa to ryzyko złamania istniejącego kodu (starszy kod mógłby używać tego słowa kluczowego jako nazwy zmiennej, klasy lub czegokolwiek innego).

Ponadto wydaje mi się, że zdefiniowanie std::initializer_listkontenera z szablonem jest dość eleganckim wyborem: gdyby było to słowo kluczowe, w jaki sposób można uzyskać dostęp do jego bazowego typu? Jak byś to powtórzył? Potrzebowałbyś również kilku nowych operatorów, a to zmusiłoby cię do zapamiętania większej liczby nazw i słów kluczowych, aby zrobić to samo, co w przypadku standardowych kontenerów.

Traktowanie std::initializer_listkontenera jak każdego innego kontenera daje możliwość napisania ogólnego kodu, który działa z każdą z tych rzeczy.

AKTUALIZACJA:

Po co więc wprowadzać nowy typ, zamiast używać kombinacji istniejących? (z komentarzy)

Na początek wszystkie inne kontenery mają metody dodawania, usuwania i umieszczania elementów, które nie są pożądane w przypadku kolekcji generowanej przez kompilator. Jedynym wyjątkiem jest to std::array<>, że opakowuje tablicę o stałym rozmiarze w stylu C i dlatego pozostaje jedynym rozsądnym kandydatem.

Jednak, jak Nicol Bolas słusznie podkreśla się w komentarzach, inny, zasadnicza różnica pomiędzy std::initializer_listi wszystkie inne standardowe pojemniki (włącznie std::array<>) jest to, że te ostatnie mają semantykę wartości , natomiast std::initializer_listma semantykę referencyjnych . Kopiowanie std::initializer_list, na przykład, nie spowoduje kopię poszczególnych pierwiastków.

Co więcej (po raz kolejny dzięki uprzejmości Nicol Bolas), posiadanie specjalnego pojemnika na listy inicjalizacji nawiasów klamrowych pozwala na przeciążenie sposobu, w jaki użytkownik wykonuje inicjalizację.

To nic nowego. Na przykład for (i : some_container)opiera się na istnieniu określonych metod lub samodzielnych funkcji w some_containerklasie. C # jeszcze bardziej polega na swoich bibliotekach .NET. Właściwie uważam, że jest to dość eleganckie rozwiązanie, ponieważ możesz dostosować swoje zajęcia do niektórych struktur językowych bez komplikowania specyfikacji języka.

To rzeczywiście nic nowego i ilu z nich zwróciło uwagę, ta praktyka istniała w C ++ i jest, powiedzmy, w C #.

Andrei Alexandrescu wspomniał jednak o dobrej uwadze w tej sprawie: możesz myśleć o niej jako o części wyimaginowanej „rdzeniowej” przestrzeni nazw, wtedy będzie to miało więcej sensu.

Tak, to rzeczywiście coś takiego: core::initializer_list, core::size_t, core::begin(), core::end()i tak dalej. To tylko niefortunny zbieg okoliczności, że stdprzestrzeń nazw zawiera w sobie pewne podstawowe konstrukcje językowe.

Nie tylko może działać całkowicie w bibliotece standardowej. Włączenie do standardowej biblioteki nie oznacza, że ​​kompilator nie potrafi płatać sprytnych sztuczek.

Chociaż może nie być w stanie tego zrobić we wszystkich przypadkach, może bardzo dobrze powiedzieć: ten typ jest dobrze znany lub typ prosty, zignorujmy initializer_listi po prostu miej w pamięci obraz tego, jaka powinna być zainicjowana wartość.

Innymi słowy int i {5};może być równoważne int i(5);lub int i=5;nawet intwrapper iw {5};Gdzie intwrapperjest prosty wrapper klasy na int z trywialny konstruktor odbywającychinitializer_list

Nie jest częścią podstawowego języka, ponieważ można go zaimplementować w całości w bibliotece, po prostu w wierszach operator newi operator delete. Jakie korzyści przyniosłoby utrudnienie kompilatorom kompilacji?