El resultado de una función de informe de estado es correcto si su resultado fue válido al menos una vez entre el momento en que se llamó y cuando regresó. Este es el caso de todas las funciones de informes de estado, como obtener espacio libre en el disco, obtener el tamaño del archivo, etc.

En algún momento tiene que obtener el estado, y no puede hacer nada para que el estado cambie antes de obtenerlo o después de obtenerlo. Así que esta tiene que ser la regla o sería imposible escribir funciones correctas.

La gente a menudo entiende esto mal. Por ejemplo, verifican si hay espacio libre en un disco y luego asumen que una escritura posterior no fallará debido a espacio insuficiente. O llaman select y luego asumen que una operación posterior no se bloqueará. Todos estos son errores.

Como dice David Schwartz , las operaciones de informes de estado, como obtener espacio libre en el disco, obtener el tamaño del archivo, verificar si existe un archivo, etc., son fundamentalmente poco confiables. Una buena manera de pensar en ellos es que devuelven estimaciones de buena fe de sus medidas, pero existe la advertencia de que las personas que llaman no deben confiar en que los valores sean correctos, ya que podrían cambiar en cualquier momento antes, después o durante la medición.

También está la cuestión de los requisitos, tanto declarados como no declarados. Prácticamente todas las funciones que escriba tendrán un requisito de rendimiento no declarado que no tardará 24 horas en ejecutarse . Ciertamente eso es cierto para conseguir una cita. ¿Qué importa cómo llames al resultado de esta función cuando la función es completamente inutilizable? Es una distinción puramente académica. En términos prácticos, la función se rompe y ningún resultado es correcto.

Para ir más lejos, ni siquiera estoy seguro de que sea una distinción académica. Está preguntando si el "tiempo de ejecución" o el "tiempo de resultado" es correcto. Ser "correcto" implica que la distinción conducirá a una acción correcta o incorrecta y necesita saber cuál será. ¿Cuáles serían esas acciones?

Si tengo razón, haría X , pero si mi amigo tiene razón, haría Y.

¿Qué son las acciones X e Y ? ¿Qué harías de manera diferente en función de cómo se resuelve este argumento? Por ejemplo, si este fuera un problema real en un sistema de emisión de boletos, ¿terminaría cerrando el problema según el resultado de su argumento, ninguno de los dos solucionó el sueño de 24 horas? ¡Espero que no!

Considere este pseudocódigo:

 fun getTomorrowsDate() sleep(getRandomValue()) today = getCurrentDate() sleep(getRandomValue()) ret = today + 1 sleep(getRandomValue()) return ret

Esto no está muy lejos de lo que realmente sucede durante CADA llamada de función. El sistema operativo puede interrumpirse en cualquier momento, por lo que, en cierto sentido, esas llamadas de suspensión realmente existen.

Entonces, a menos que haya tomado medidas muy cautelosas para hacer que su función sea atómica, la única diferencia entre el pseudo anterior y su ejemplo de código es que ha asegurado que un evento que siempre tiene una probabilidad distinta de cero tiene una probabilidad del 100%.

David y John dieron buenas respuestas, así que no daré más detalles. Solo quería agregar este ejemplo.

En mi opinión, esta función tiene la semántica de getCurrentDate y podría mantener ese nombre. Porque se espera que getCurrentDate devuelva alguna fecha que se garantiza que ocurra entre el momento de la llamada y el momento de la devolución. (Piense en lo que sucede si llama a la función estándar diez nanosegundos antes de la medianoche, de modo que la fecha cambie durante la llamada).

Por cierto, ni siquiera sé si las implementaciones existentes imponen el requisito de "intermediación" anterior. (Por ejemplo, la regla podría romperse si la función intentara compensar su propia latencia).