On Thursday, 16 May 2019 at 20:31:23 UTC, Vladimir Panteleev wrote:
> On Thursday, 16 May 2019 at 20:17:37 UTC, Steven Schveighoffer

[...]

>> hnsecs is more confusing than nanoseconds. People know what a nanosecond is, a hecto-nano-second is not as familiar a term.
>
> Agreed, which is why Duration.toString shouldn't be used to present durations to users.
>
> Developers, however, are expected to know what a hectonanosecond is, same as with all the other technical terms.

"hectonanosecond" looks like an illegal combination of SI prefixes [1]. I recommend changing the meaning of hnsecs to "[one] hundred nanoseconds".

[1] "Prefixes may not be used in combination."
    https://en.wikipedia.org/wiki/Metric_prefix

On 16.05.19 17:55, Vladimir Panteleev wrote:
> On Thursday, 16 May 2019 at 15:52:05 UTC, Steven Schveighoffer wrote:
[...]
>> The output shouldn't involve the inner workings of the type. It should be changed to say 10 ns.
> 
> If the output is meant for the developer, then I disagree subjectively, as that creates the impression that the lowest resolution or representable unit of time is the nanosecond.
> 
> If the output is meant for the user, then hectonanoseconds or nanoseconds are going to be almost always irrelevant. The duration should be formatted appropriately to the use case.
> 

I'd suggest "17 ms, and 553.1µs" for a better default (1 hns is 0.1 µs, right?). No weird "hnsecs", no false precision, still all the data that is there.

On Friday, 17 May 2019 at 18:36:00 UTC, ag0aep6g wrote:
> I'd suggest "17 ms, and 553.1µs" for a better default (1 hns is 0.1 µs, right?). No weird "hnsecs", no false precision, still all the data that is there.

I was going to propose the same. Hns is weird.

Bastiaan.

On Friday, 17 May 2019 at 20:30:56 UTC, Bastiaan Veelo wrote:
> On Friday, 17 May 2019 at 18:36:00 UTC, ag0aep6g wrote:
>> I'd suggest "17 ms, and 553.1µs" for a better default (1 hns is 0.1 µs, right?). No weird "hnsecs", no false precision, still all the data that is there.
>
> I was going to propose the same. Hns is weird.

Why not simply 17.5531 ms ("%.4f ms") to get rid of the non-ASCII µ prefix?

On Friday, 17 May 2019 at 18:02:04 UTC, kdevel wrote:
> On Thursday, 16 May 2019 at 20:31:23 UTC, Vladimir Panteleev wrote:
>> On Thursday, 16 May 2019 at 20:17:37 UTC, Steven Schveighoffer
>
> [...]
>
>>> hnsecs is more confusing than nanoseconds. People know what a nanosecond is, a hecto-nano-second is not as familiar a term.
>>
>> Agreed, which is why Duration.toString shouldn't be used to present durations to users.
>>
>> Developers, however, are expected to know what a hectonanosecond is, same as with all the other technical terms.
>
> "hectonanosecond" looks like an illegal combination of SI prefixes [1]. I recommend changing the meaning of hnsecs to "[one] hundred nanoseconds".
>
> [1] "Prefixes may not be used in combination."
>     https://en.wikipedia.org/wiki/Metric_prefix

It through me off, it really  makes no sense. The purpose of a prefix is to define something better. hectonano seems contradictory... and is it any different than nanohecto?

There really is no point in it, the whole reason for the metric system is to provide a hierarchical resolution. Just use nano or pico....

On Thursday, 16 May 2019 at 15:19:03 UTC, Alex wrote:
> 1 - 17 ms, 553 ╬╝s, and 1 hnsec
>
> fancy useless asci hieroglyphic
>

Holy shirt!
All that time I was thinking this is just some sort of encoding artifacts in terminal(common problem on windows), especially because IIRC on Linux it is displaying this greek 'micro' correctly.

This is completely out of context, and so should be replaced with something more conventional...

Now when I realize it, for me it immediately start look like some sort of cave art or graffiti in art gallery, very unprofessional I say.

On Saturday, 18 May 2019 at 00:17:20 UTC, kdevel wrote:
> Why not simply 17.5531 ms ("%.4f ms") to get rid of the non-ASCII µ prefix?

fwiw I like this solution for the output. It is very clear to me.

On Thursday, 16 May 2019 at 15:19:03 UTC, Alex wrote:
> 1 - 17 ms, 553 ╬╝s, and 1 hnsec

That's µs* for micro-seconds.

* hurrah for French keyboard which has a rarely used µ key, but none for Ç a frequent character of the language.

>
> WTH!! is there any way to just get a normal u rather than some fancy useless asci hieroglyphic? Why don't we have a fancy M? and an h?
>
> What's an hnsec anyways?

On Saturday, 18 May 2019 at 20:34:33 UTC, Patrick Schluter wrote:
> * hurrah for French keyboard which has a rarely used µ key, but none for Ç a frequent character of the language.

<Caps Lock><key marked with '9' on the number row><Caps Lock>

On Saturday, 18 May 2019 at 21:05:13 UTC, Les De Ridder wrote:
> On Saturday, 18 May 2019 at 20:34:33 UTC, Patrick Schluter wrote:
>> * hurrah for French keyboard which has a rarely used µ key, but none for Ç a frequent character of the language.
>
> <Caps Lock><key marked with '9' on the number row><Caps Lock>

That's the lowercase ç. The uppercase Ç is not directly composable, annoying or to say it in French to illsutrate: "Ça fait chier". I use Alt+1+2+8 on Windows, but most people do not know these ancient OEM-437 based character codes going back to the orignal IBM-PC. The newer ANSI based Alt+0+1+9+9 is one keypress longer and I would have to learn actually the code.

There are 2 other characters that are not available on the french keyboard: œ and Œ. Quite annoying if you sell beef (bœuf) and eggs (œufs) in the towns of Œutrange or Œting.