Date: Wed, 3 May 2023 12:05:53 -0400
On Wed, May 3, 2023 at 11:21 AM Simon Hill via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> > I don't really see a pressing need for this. If you don't want fractional seconds, don't use a representation that has subsecond resolution.
>
> I don't see a _pressing need_ either. It's just, IMHO, a very tiny QoL tweak.
>
> The standard doesn't specify whether or not the standard clocks actually have subsecond resolution (yes, you can obtain it in code, but that doesn't reduce verbosity). Also, you might want that precision elsewhere (I did).
> In the worst (albeit unlikely) case, if a clock currently has seconds resolution but is upgraded in the future, formatting could change. For example, file_clock.
You're thinking about it the wrong way. The solution is not "trust the
clock's resolution". It's "set the resolution you want out of the
clock".
> I do understand though that it's simple to just pass std::chrono::floor<std::chrono::seconds>(t) and be safe.
> But "std::chrono::floor<std::chrono::seconds>(t)" is still much more verbose than "(t)".
Sure. And?
Think about it from the perspective of what the user is doing. A user
has a time. They either retrieved that time for the sole purpose of
converting it to text, or they are using the time for other things and
want to convert it to text. In the latter case, why would you do text
conversion in a way that doesn't store all of the information in the
time? Wouldn't it make more sense to store the whole thing, if that's
the formatting you asked for? If you're only going to convert it to
seconds precision, wouldn't it make more sense to store it that way?
Equally importantly, if your intention is specifically to put less
precision into the text than the time actually stores... maybe
verbosity is a *good thing*. That sounds like the sort of thing you
can do by mistake.
All that being said, there is one clear advantage to your idea: cases
where the format string is not known at the site of the use of the
format string. The format string could come from a translation file, a
macro, or somewhere else. And it would be good if those places could
have more control over the formatting precision.
<std-proposals_at_[hidden]> wrote:
>
> > I don't really see a pressing need for this. If you don't want fractional seconds, don't use a representation that has subsecond resolution.
>
> I don't see a _pressing need_ either. It's just, IMHO, a very tiny QoL tweak.
>
> The standard doesn't specify whether or not the standard clocks actually have subsecond resolution (yes, you can obtain it in code, but that doesn't reduce verbosity). Also, you might want that precision elsewhere (I did).
> In the worst (albeit unlikely) case, if a clock currently has seconds resolution but is upgraded in the future, formatting could change. For example, file_clock.
You're thinking about it the wrong way. The solution is not "trust the
clock's resolution". It's "set the resolution you want out of the
clock".
> I do understand though that it's simple to just pass std::chrono::floor<std::chrono::seconds>(t) and be safe.
> But "std::chrono::floor<std::chrono::seconds>(t)" is still much more verbose than "(t)".
Sure. And?
Think about it from the perspective of what the user is doing. A user
has a time. They either retrieved that time for the sole purpose of
converting it to text, or they are using the time for other things and
want to convert it to text. In the latter case, why would you do text
conversion in a way that doesn't store all of the information in the
time? Wouldn't it make more sense to store the whole thing, if that's
the formatting you asked for? If you're only going to convert it to
seconds precision, wouldn't it make more sense to store it that way?
Equally importantly, if your intention is specifically to put less
precision into the text than the time actually stores... maybe
verbosity is a *good thing*. That sounds like the sort of thing you
can do by mistake.
All that being said, there is one clear advantage to your idea: cases
where the format string is not known at the site of the use of the
format string. The format string could come from a translation file, a
macro, or somewhere else. And it would be good if those places could
have more control over the formatting precision.
Received on 2023-05-03 16:06:04