Add support for some chrono-based types

[rcalixte]

This covers the majority of types from std::chrono* used throughout Qt and the related ecosystem. There are some additional variants that currently yield little value and more variants that will possibly be adopted upstream once C++23 is the standard. Currently, there are also no pointer-based considerations for these types that I am aware of which keeps the implementation mostly simple.

One consideration is how would be the best way to surface to the library consumer which specific unit the library is expecting? This can be discovered by inspecting the code but I wonder if you have any ideas here.

The update to the example is a bit gratuitous so that commit can be dropped if you feel. I didn't think this would merit an entire new example. 😅

[mappu]

👍 Looks great! Always nice to get a few more methods exposed.

how would be the best way to surface to the library consumer which specific unit the library is expecting?

The really idiomatic thing in Go would be to convert them to stdlib time.Duration (an int64 number of nanoseconds) - although for usec/msec/sec that would lose integer range.

Another idea would be to define a new Go type for each one - type Nanoseconds int64 - and have an explicit mapping,

The quickest fix would probably be to rename the parameter to foo_Nanoseconds, but that doesn't work for return values.

[rcalixte]

Another idea would be to define a new Go type for each one - type Nanoseconds int64 - and have an explicit mapping,

I think I'll try this path. My only concern is that we might have a namespace collision with any methods of the same name. Should we try to do it at the main package level or define locally on an as-needed basis?

[mappu]

Should we try to do it at the main package level or define locally on an as-needed basis?

The downside of doing it locally as-needed is that different chrono::nanoseconds types would be treated as independent types. So i have a slight preference for doing it centrally somehow, but either would probably work.

At the main package level, there used to be things like this in binding.go - or there is also the libmiqt/ package that we're not making much use of.

[rcalixte]

At the main package level, there used to be things like this in binding.go

Thanks for your guidance here! I've added the typedefs to the binding.go for each library. It turns out I was premature on naming collisions.