On Wednesday, 5 September 2012 at 11:50:12 UTC, bearophile wrote:
> Don Clugston:
>
>> I'd be interested to know if that idea is ever used in real code. I mean, it's a classic trendy template toy, but does anyone actually use it?
>
> As usual I don't have usage statistics.
>
> I like dynamic languages, like Python. But if you give me a static type system, then I want something back from the language. Detecting certain bugs at compile-time is one way to pay me back.
>
> If you want most programmers to use a feature like units, it needs:
> - Built-in, in the standard library, or easy to install;
> - To have a compact and very nice looking syntax;
> - Easy enough to use;
> - Flexible, to be able to represent all units you find in many real problems;
> - Have zero or near-zero run-time costs, in both CPU and memory;
> - Give acceptable error messages.
>
> I think in F# people are using units often enough.
>
> If a units system will be present in Phobos and it will be very good to use, maybe D programmers will use them.
>
> I am currently using Haskell a little, and I am enjoying giving types to values to tell them apart in terms of their usage.
>
>
>> I say this because I've done a lot of physics calculation involving multiple complicated units, but never seen a use for this sort of thing.
>> In my experience, problems involving units are easily detectable (two test cases will catch them all).
>> The most insidious bugs are things like when you have used constants at 25'C instead of 20'C, or when you have a sign wrong.
>
> There are some famous problems caused by mixing units:
> http://lamar.colostate.edu/~hillger/unit-mixups.html
>
> Maybe this is the most famous:
> http://mars.jpl.nasa.gov/msp98/news/mco990930.html
>
> Bye,
> bearophile

FWIW, there was a proposal (JSR-275) to add support for units of measure to Java that was ultimately rejected. The implementation can be found at JScience.org, written and maintained by the website owner, Jean-Marie Dautelle, who also led the JSR team.

Paul

Thank you everyone for your replies.

Initially I think I am going to role my own as my requirements are fairly simple compared to a full blown system with units of measure. My goal is to have large number of application specific types which may be implemented as the same but are semantically different.

A real world case in which I have used this approach was when cleaning up a large body of code using a mixture of time units (sec,msec,µsec) stored as 32 and 64bit signed and unsigned integers. We needed to standardized on µsec and explicit typing greatly simplified the migration process.

I have also worked on protects in the past where we speculated on the benefits of using strong typing to avoid incorrect mixing of matrices (world, model, bone etc.). I think there is allot of value to be had in simply requiring explicit casting however I am less convinced on systems that allow implicit combining of units of the same quantity type. I feel part of the type is its range and precision and so there is no valid way to implicitly add kilometers to millimeters for example.

I hope that at some point support for the semantically different versions of the same type will be added to the standard library but for now I am happy to write my own. D is still a new language to me and it has some vary nice features to help accomplish this.

Nicholas Londey:

> however I am less convinced on systems that allow implicit combining of units of the same quantity type. I feel part of the type is its range and precision and so there is no valid way to implicitly add kilometers to millimeters for example.

I see. If the range and precision are statically know then it's possible to design types that contain such values too. If they are known at run-time they need some run-time tests.

Bye,
bearophile

On Wednesday, 5 September 2012 at 05:53:49 UTC, anonymous wrote:
> I noticed two flaws in std.units:
> 1) Can't add quantities of the same type (this is probably trivial to fix).
> 2) Different scopes don't make different quantity types.

Can you elaborate on that? I must admit that I didn't actively work on std.units for quite some while now, as general interest in it seemed to have faded (I'm glad to be proven wrong, though), but adding quantities of the same type should definitely work. And what do you mean by "different scopes"? If the unit types are different, the quantity types should be different as well.

David

On Thursday, 6 September 2012 at 12:22:08 UTC, David Nadlinger wrote:
> Can you elaborate on that? I must admit that I didn't actively work on std.units for quite some while now, as general interest in it seemed to have faded (I'm glad to be proven wrong, though), but adding quantities of the same type should definitely work.

Maybe I'm missing something fundamental, but this little test fails:
---
auto foo = baseUnit!"foo";
auto foo2 = foo + foo;
---
Error: incompatible types for ((foo) + (foo)): 'BaseUnit!("foo",null)' and 'BaseUnit!("foo",null)'

> And what do you mean by "different scopes"? If the unit types are different, the quantity types should be different as well.

In the following, S1.foo and S2.foo are of the same type. I think they shouldn't be; just like S1.Bar and S2.Bar are different types.
---
struct S1 {enum foo = baseUnit!"foo"; struct Bar {}}
struct S2 {enum foo = baseUnit!"foo"; struct Bar {}}
---