Исправление
vertexua,
(текущая версия)
:
Я все к тому, что
Оптимальным видится такой вариант использования: переменная, заполняемая из внешнего источника -> наложение constraint'ов -> внутренняя переменная с мета-тегом «пройдён constraint такой-то».
все так и делают. Код написаный в компаниях, где следят за стилем кода во врема ревью (не как васян захотел, а ревьювер проверяет что если язык позволяет писать голые типы, то никто не пишет голые типы). Никто не бегает (с голой жопой) с миллисекундами в int64 (или секундами? или микросекундами? или что это вообще такое?), а люди сразу конвертируют это в Time/Duration. Или идут дальше и конвертируют в еще более ограниченый тип, которые прошел еще более жесткую валидацию (например что это последний год) и дальше не парятся и пользуются уже провереным типом.
И Time нельзя сложить с Time. Но можно с Duration. Duration можно сложить или отнять. Time можно отнять от Time и получить Duration. А для процессора это все просто будет int64, из-за подхода zero cost abstraction
Исходная версия
vertexua,
:
Я все к тому, что
Оптимальным видится такой вариант использования: переменная, заполняемая из внешнего источника -> наложение constraint'ов -> внутренняя переменная с мета-тегом «пройдён constraint такой-то».
все так и делают. Код написаный в компаниях, где следят за стилем кода во врема ревью (не как васян захотел, а ревьювер проверяет что если язык позволяет писать голые типы, то никто не пишет голые типы). Никто не бегает (с голой жопой) с миллисекундами в int64 (или секундами? или микросекундами? или что это вообще такое?), а люди сразу конвертируют это в Time/Duration. Или идут дальше и конвертируют в еще более ограниченый тип, которые прошел еще более жесткую валидацию (например что это последний год) и дальше не парятся и пользуются уже провереным типом.