Jemand aus dem Publikum stellte während des Vortrags "C ++ Standard Library Panel" auf der CppCon 2016 ( YouTube ) eine Frage zum Potenzial des Namens experimental, Benutzer davon abzuhalten , irgendetwas innerhalb des Namespace zu verwenden:
Hält ihr [den Inhalt des std::experimentalNamespace] für produktionsbereit und ist das ein Argument, das vorgebracht werden kann, [dass] es für die nächsten 3 Jahre effektiv produktionsbereit ist, und vielleicht müssen Sie Ihren Code 3 Jahre später ändern, vielleicht?
Michael Wong (Vorsitzender von SG5 und SG14 und Herausgeber der Concurrency TS) stellte zunächst die Frage:
Ich denke, innerhalb des Komitees herrscht starker Konsens darüber, dass es praktisch produktionsbereit ist. Wie ich bereits sagte, werden in den meisten Fällen 99% davon in die Luft geschleudert. Wir möchten sicherstellen, dass es für Sie kein Hindernis ist, es zu verwenden. Sie können verstehen, warum wir große Features, große Gruppen von Features, in einen solchen Kontext stellen möchten, damit der Rest des gesamten Bibliothekssystems nicht gestört wird, aber es Ihnen auch die Verwendung erleichtert. Jetzt können Sie GCC mit einem bestimmten Flag für Konzepte aktivieren, das es Ihnen tatsächlich erleichtert, es zu segmentieren.
Alisdair Meredith (ehemaliger Vorsitzender der LWG) folgte dann:
Ich werde hier die gegenteilige Position einnehmen. Eines der Dinge, die Herb [Sutter] als Veranstalter von WG21, der Standardgruppe, sagte, als wir uns auf den Weg zu TSes machten, war, dass er nicht glaubte, dass TSes erfolgreich sein werden, bis wir es nicht geschafft haben, etwas voranzubringen, weil es Das heißt, wir sind nicht experimentell genug, wir sind nicht ehrgeizig genug, wofür wir die TSes verwenden. Das wollen wir wirklichexperimentalUm ein Hinweis zu sein, dass sich diese Dinge ändern können, sind wir daran nicht gebunden und können etwas falsch machen. Dies soll unsere Barriere für die Dinge senken, die wir als so ehrgeizig und erreichbar wie möglich betrachten. [...] Jetzt scheint der Standard in einem dreijährigen Veröffentlichungszyklus zu liegen. Wir sollten viel ehrgeiziger sein, wenn es darum geht, wirklich experimentelle Funktionen zu entwickeln in die TS, und vielleicht schneller in den Hauptstandard selbst voranbringen. Aber auch dies wird ein unterhaltsames Thema sein, das wir bei den nächsten [C ++ Standard Committee] -Sitzungen diskutieren werden.
Stephan T. Lavavej (Betreuer der STL-Implementierung von Microsoft) antwortete zuletzt:
Es ist wichtig, zwischen der Experimentierbarkeit der Schnittstelle und der Experimentierbarkeit der Implementierung zu unterscheiden, denn wenn Sie "produktionsbereit" sagen, was bedeutet das? Normalerweise, "produktionsbereit", würden Sie daran denken, dass Sie über die Implementierung sprechen. Es ist durchaus möglich, dass eine Implementierung [von etwas in std::experimental] absolut kugelsicher ist. [...] So etwas wie [...] der <random>Header in TR1, [es war] wirklich sehr, sehr schön in TR1, und Sie hätten eine absolut kugelsichere Implementierung davon haben können, aber es stellte sich heraus, dass die Schnittstelle durcheinander geraten ist Im Wesentlichen [vor der Veröffentlichung von] C ++ 11 und [...] wenn wir damals wüssten, was wir jetzt tun, wäre das Einfügen eines experimentalein besseres Signal für die Leute gewesen: "Hey, vielleicht willst du das nicht verwendenstd::experimental::variate_generator weil, ha-ha, es in C ++ 11 verschwinden wird ".
Es scheint also, dass unter den Standardbibliotheksentwicklern und Komiteemitgliedern ein gewisser Wunsch besteht, dass zumindest in Zukunft der Inhalt des std::experimentalNamespace wirklich "experimenteller" Natur sein sollte und es nicht als selbstverständlich angesehen werden sollte, dass etwas im std::experimentalWillen ist mach es in den C ++ Standard.
Und nein, soweit ich weiß, liegt es an den Standard-Bibliotheksanbietern, ob sie Implementierungen für die verschiedenen darin enthaltenen Funktionen bereitstellen std::experimental.