¿Son las características experimentales de C++ moderno confiables para proyectos a largo plazo?

Alguien de la audiencia hizo una pregunta durante la charla" C++ Standard Library Panel " en CppCon 2016 ( YouTube ) sobre el potencial del nombre experimental para asustar a los usuarios de usar cualquier cosa dentro del espacio de nombres:

¿Consideran que[el contenido del espacio de nombres std::experimental] está listo para la producción y es un argumento que se puede hacer, [que] está efectivamente listo para la producción para los próximos 3 años, y tal vez tenga que cambiar su código 3 años más tarde, tal vez?

Michael Wong (presidente de la SG5 y la SG14 y editor de la Concurrencia TS) envió la pregunta primero:

Creo que hay un fuerte consenso dentro del comité de que prácticamente está listo para la producción. Como dije antes, en la mayoría de los casos, el 99% de ella se deja caer en el aire. Queremos asegurarnos de que no sea un impedimento para que lo use. Puede entender por qué queremos poner grandes características, grandes grupos de características, en un contexto así, para que no moleste el resto de todo el sistema de la biblioteca, pero también hace que sea más fácil para usted usarlo. Ahora se puede activar GCC con una bandera específica para los conceptos, ya sabes, que en realidad hace que sea más fácil para usted para segmentarlo.

Alisdair Meredith (ex presidente del Grupo de Trabajo de LWG) luego siguió:

Voy a tomar la posición contraria aquí. Una de las cosas que Herb [Sutter] dijo como coordinador del WG21, el grupo estándar, cuando partimos por el camino de las EET es que no pensó que las EET habrán tenido éxito hasta que no hayamos logrado sacar algo adelante, porque significa que no estamos siendo lo suficientemente experimentales, no estamos siendo lo suficientemente ambiciosos en lo que estamos utilizando las EET para. Realmente queremos que experimental sea una pista de que, sí, estas cosas están sujetas a cambios, no estamos vinculados a eso, y podemos equivocarnos. Esto es para bajar nuestra barrera para las cosas que consideramos que son tan ambiciosas y alcanzar como podemos [...] Ahora el estándar parece estar en una versión de tres años ciclo, deberíamos ser mucho más ambiciosos en poner características realmente experimentales en la TS, y tal vez avanzar las cosas más rápidamente en el estándar principal en sí. Pero de nuevo, este será un tema divertido para que lo discutamos en las próximas reuniones del comité de estándares de C++.

Stephan T. Lavavej (mantenedor de la implementación STL de Microsoft) fue el último en responder:

Es importante hacer una distinción entre la experimentalidad de la interfaz y la experimentalidad de la implementación, porque cuando dices "listo para la producción", ¿qué significa eso? Por lo general," listo para la producción", se podría pensar en que hablar de la implementación. Es muy posible que una implementación [de algo en std::experimental] sea absolutamente [...] antibalas. [... Algo así como [...] el encabezado <random> en TR1, [era] muy, muy agradable en TR1, y podrías haber tenido una implementación absolutamente a prueba de balas de eso, pero resultó que la interfaz batía sustancialmente [antes del lanzamiento de] C++11 y [...] si supiéramos entonces lo que hacemos ahora, poner un experimental habría sido una mejor señal para la gente de que, "Oye, tal vez no quieras usar std::experimental::variate_generator porque, ja, ja, va a desaparecer en C++11".

Así que parece que hay algún deseo entre los desarrolladores de bibliotecas estándar y los miembros del comité de que, al menos en el futuro, el contenido del espacio de nombres std::experimental debe ser verdaderamente "experimental" en naturaleza, y no debe ser se da por sentado que algo en std::experimental lo convertirá en el estándar de C++.

Y no, por lo que entiendo, depende de los proveedores de bibliotecas estándar si proporcionan implementaciones para las diversas características dentro de std::experimental.

"Experimental" es un término ligeramente exagerado. La biblioteca filesystem se originó en Boost y pasó por algunas iteraciones allí, antes de ser enviada a ISO.

Sin embargo, las normas ISO son intencionalmente muy conservadoras. Llamándolo experimental significa que ISO explícitamente no promete que el nombre será estable; está muy claro que tendrá que volver a dirigir su código en algún momento en el futuro. Pero conociendo ISO, es probable que haya orientación cuan.

En cuanto a la compatibilidad entre compiladores, espere que sea razonable. Pero habrá casos de esquina (piense en las rutas relativas a la unidad de Windows, por ejemplo), y es exactamente por eso que un estándar futuro podría romper su código existente. Idealmente, te rompería el código si y solo si dependías de ese caso de esquina, pero eso no es una garantía.

Tal vez haya más cosas sobre las que preguntarse.

Algunos puntos a considerar:

• ¿Qué tan multiplataforma es tu proyecto? Si solo hay un compilador involucrado, entonces puede inspeccionar su implementación y historial para decidir. ¡O pregúntales!

• ¿Qué tan grande es tu base de código? Cuán grande sería el impacto de los cambios?

• Qué tan fundamentales para su proyecto son las características proporcionadas por el API / biblioteca / característica?

• ¿cuáles son las alternativas?

  • Use la característica experimental, luego adapte el código a las modificaciones cuando/si se estandariza. Puede ser tan fácil como eliminar experimental::, o tan difícil como forzar soluciones alternativas.
  • Añadir una capa de abstracción (comentario de Serge Ballesta). Si la característica experimental cambia, las reescrituras se aíslan. Para una característica estándar, podría ser overkill (std:: filesystem ya es una capa de abstracción...).
  • Uso otra API/biblioteca. Las mismas preguntas: ¿madurez? la robustez? ¿estabilidad? la portabilidad? facilidad de uso? características?
• En el caso de std:: filesystem (o el TS de red), existe boost:: filesystem (resp. boost:: asio) como alternativa o alternativa, en caso de que el experimental falle o desaparezca.