On Thursday, 17 March 2016 at 12:51:28 UTC, Nordlöw wrote:
> I believe `isConvertableTo` is a more Phobos-compliant naming, right?

Correction: Should be named `isConvertibleTo`.

BTW: We already have https://dlang.org/phobos/std_traits.html#isImplicitlyConvertible

Why don't we already have

    isConvertibleTo

or/and

    isExplicitlyConvertibleTo

On Thursday, 17 March 2016 at 12:55:39

Ping, David Nadlinger! 😊

On Thursday, 17 March 2016 at 12:51:28 UTC, Nordlöw wrote:
> I believe `isConvertableTo` is a more Phobos-compliant naming, right?

I went for canConvert since it is a bit shorter than isConvertible and there is precedent for it in Phobos as well (e.g. find/canFind). It's a matter of taste, though. If I were to work on the library again today, I might just as well go for isConvertible.

> Is there are reason why `convert` wasn't named the shorter and Phobos-compliant `to` instead?

One thing to consider is that convert!U differs from to!T in that the latter returns something of type T, whereas the former returns a Quantity!(U, …). This seems enough of a difference that choosing the same name as the widely used std.conv.to might be somewhat misleading (even though I usually advocate for using the module system for disambiguating names).

>> function, you then simply use cos(angle.convert!radian / radian) or whatever.
>
> Why not simply add a Quantity member […] toValue()

This is again a design decision that can go either way. The choice I made was deliberate, although of course not above debate:

Since I chose to have dimensionless quantities implicitly convert to "plain" value types, it seemed superfluous to add another primitive (`a / a.unit` is simple enough to write). Furthermore, it underlines the point that `*` and `/` between quantities and units do not actually change the numeric value, but merely modify its units. Making use of that for the "core functionality" seemed like a cute way to drive the point home to users. Explicitly specifying the unit also helps avoiding mistakes in generic code.

If you want to go the other route, I would suggest carefully deliberating the naming scheme, since discarding unit information is a lossy and potentially "unsafe" (as in code correctness). In an attempt to make this obvious in the current implementation (where it is only enabled for dimensionless quantities), I named the function rawValue(). For example, renaming (fromValue, rawValue) to {from, to}Raw() might be clearer than {from, to}Value().

By the way, I highly doubt that "puts less stress on the compiler" is a valid argument for that decision. In that regard, the big elephant in the room is GetConversion, which you might want to re-do using a breadth-first search anyway (see TODO comments; I couldn't be bothered to implement it back then due to the numerous DMD bugs I had to fight).

 — David

On Tuesday, 12 April 2011 at 16:44:10 UTC, David Nadlinger wrote:
> Recently, I have been playing around with a little units of measurement system in D. As this topic has already been brought up quite a number of times here, I thought I would put my implementation up for discussion here.
>
> When this topic came up previously, it has been proposed to include units support with Phobos, and thus I have merged my work into my Phobos fork. Please note, however, that even if we should come to the conclusion that we really want something like this in Phobos, this is not a formal review request yet. There are still a couple of items left on my to-do list, but I'd like to get some feedback first.
>
> Anyway, here is a link to the code: https://github.com/klickverbot/phobos/tree/units (std/units.d and std/si.d). Also, I put up a build of the DDoc output at http://klickverbot.at/code/units/std_units.html resp. http://klickverbot.at/code/units/std_si.html.
>
>
>
> David

Impressive! I like the idea, in special when you can handled derived units and doing conversions like this :

convert!(kilo(newton))(2000000 * gram * meter / pow!2(second)));

On Tuesday, 22 March 2016 at 09:55:28 UTC, Zardoz wrote:
>
> Impressive! I like the idea, in special when you can handled derived units and doing conversions like this :
>
> convert!(kilo(newton))(2000000 * gram * meter / pow!2(second)));

Wow that's pretty sweet!
So @nordlow how about pushing this code to a separate repository and dub?
It seems that now there is enough interest in pushing this :)

> I would like to move forward with std.experimental.unit(s).

+1 for pushing this to Phobos!

On Tuesday, 29 March 2016 at 12:46:44 UTC, Seb wrote:
> So @nordlow how about pushing this code to a separate repository and dub?

Here you are:

https://github.com/nordlow/units-d