[GSoC Proposal] Statically Checked Measurement Units

[David Nadlinger]

On 3/28/11 5:43 PM, Cristi Cobzarenco wrote:
> First, let me apologize for this very late entry, it's the end
> of university and it's been a very busy period, I hope you will still
> consider it.

This is by no means a late proposal – the application period has not 
even formally opened yet.

I was somewhat surprised to see your post, because I had been playing 
around with a dimensional algebra/unit system implementation for a while 
before the whole GSoC thing started. I even have an unfinished project 
proposal for it lying around, but as I thought that I was rather alone 
with my fascination for unit systems, I decided to finish the Thrift one 
first. Well, seems like I was wrong… :)

A few things that came to my mind while reading your proposal:
  - The need for numerical ids is not inherent to a dimension-aware 
model like Boost.Units – it's just needed because there is no way to get 
a strict total order of types in C++. You will need to find a solution 
for this in D as well, because you want to make sure that »1.0 * second 
* metre« is of the same type as »1.0 * metre * second«.

  - I think that whether disallowing implicit conversion of e.g. 
millimeters to meters is a good idea has to be decided once the rest of 
the API has been implemented and one can actually test how the API 
»feels« – although I'd probably disallow them in my design by default as 
well, I'm not too sure if this actually works out in practice, or if it 
just cumbersome to use. Also, I'd like to note that whether to allow 
this kind of implicit conversions doesn't necessarily depend on whether 
a system has the notion of dimensions.

  - Not that I would be too fond of the Boost.Units design, but 
»convenience« functions for constructing units from strings like in your 
second example could be implemented for it just as well.

  - You have probably already thought of this and omitted it for the 
sake of brevity, but I don't quite see how your current, entirely 
string-based proposal would work when units and/or conversion factors 
are defined in a module different from the one the implementations of 
Quantity/convert/… are in. Contrary to C++, D doesn't have ADL, so I am 
not sure how a custom base unit would be in scope for Quantity to find, 
or how a custom conversion template could be found from convert().

Anyway, I am not sure whether I should submit my own units proposal as 
well, but if you should end up working on this project, I'd be happy to 
discuss any design or implementation issue you'd like to.

David