> Во-первых, тебя сейчас понесло в сторону. Даже если ты прав, то ты
> описываешь _ещё_ один источник удивления для программиста, не отменяя при этом
> тот, который описываю я.

Ну да, когда состояние где-то сохраняется - это потенциальный источник ошибок. Некоторые этому почему-то удивляются. Я правильно понимаю, что Rust в основе своей функциональный с императивными возможностями? Тогда предложенная тобой запись там м.б. корректна.

> Во-вторых, ...
>> К моменту проверки my_struc.field тот момент "сейчас" уже в прошлом, Солнце могло зайти.
> То есть gettimeofday нельзя вызывать, потому что когда мы получили результат он
> уже неактуален? И сохранение файла с таймстампом некорректно, потому что таймстамп
> уже в момент сохранения отстаёт от текущего времени, и с каждой
> прошедшей секундой отстаёт ещё на секунду, так?

Всё это в ряде случаев следует учитывать, но обычно прокатывает и так, поскольку ОС не является системой реального времени. С gettimeofday() дело обстоит ещё хуже, поскольку разрешение таймера даёт погрешность.

>> Корректна следующая конструкция, где результат 2 вполне допустим
> Нет. Если следовать твоей логике то он тоже недопустим, поскольку возврат из
> функции занимает время, за которое Солнце вполне могло зайти. Корректным способом
> будет лишь
> 1. sun.lock() -- залочили солнце, и всё связанное с ним, чтобы оно
> не меняло своего состояния
> 2. вызвали does_sun_shines_now, обработали результат
> 3. sun.unlock()

Этот неудобный момент обходится за счёт т.н. sequence points.