Johel Ernesto Guerrero Peña
Johel Ernesto Guerrero Peña
When implementing this change, you should consider changing the primary templates of unit type traits to not define the type aliases to `void`, and do like the standard type traits...
To implement this, what before might have been a compile error with some nice static assertion messages, would become a "novel" of errors, as said in [the video](https://youtu.be/PFdWqa68LmA) linked in...
Not really. It only slightly improved existing use of SFINAE. Many signatures still need them, like the in-class unit ordering operators, which should check for `is_same_dimension`. But it can certainly...
I am ashamed to say that I have yet to enable CI in any of my repositories, so I have no experience with that. EDIT: And rather than checking for...
>I'd choose the options that keep intact as much code as possible. This has proven hard. I'm reducing its scope to the operators, which are mostly formatted uniformly. I'm thinking...
To ease code review, as above, I think https://github.com/nholthaus/units/blob/5483589322daad285eedd4e2822058ba4e6640d8/.clang-format#L58 should be changed to [`Never`](https://web.archive.org/web/20171213185111/http://clang.llvm.org/docs/ClangFormatStyleOptions.html). It seems that my browser renders the tabs with 8 characters, so the diffs don't show...
`conversion_factor` is the best name.
Now it is easier: `42_s + units::unit(1s)`. But not the most easy: `42_s + 1s`.
It's your call whether this is absolutely necessary. I just though it'd be nice if the library was interoperable. Of course, I do believe that the type of `1_s +...
> I could probably achieve this by adding some new base units and strong-type wrapping these I think a separate base dimension does the job.