physical units checked at compile time (yet lacking IFTI capabilities)

[Norbert Nemec]

Dan wrote:
> I don't mean to rain on your parade, but I tend to think the units should be
> under a namespace other than the global one.

Maybe. I did not even think about that, yet.

Now, thinking of it, I'm not sure whether I would go for a separate
namespace. Of course, they will be in a separate module, but inside
that, I would rather choose full names like "meter", "liter", "second",
"hour" etc. instead of abbreviations ("m", "l", "s", "h"). And with
these full names, I think the namespace-pollution is not that large:
only few unit names are really likely to be used for other symbols in a
program (especially in a program that deals with physics)

> I also think the unit.d should most definitely be inlined because the few dude
> already wrote are a drop in the bucket compared to the full barrage of units
> that we use.  There will be *alot* of code in that file that will be useless in
> any given program.

Guess, the units should be grouped into sub-modules. If you want to use
only SI units, you don't need the thousands of ancient units that can be
found in history books.

> 
> Uncompiled code size doesn't matter for anything other than the amount of time
> spent compiling (and scrolling).  Templates aren't needed, they just make code
> more legible.

Sorry, I don't get your point here. The templates in my proof-of-concept
code are essential for the functionality and have nothing to do with
legibility. Each physical dimension defines a type (like meter,
squaremeter, cubicmeter, ...) the list of these possible types is
infinite, so you cannot explicitely define all of them by hand. Only a
limited set of types has legible names (which are defined as aliases)
but also combined dimensions like m^3*s/kg^13 could occur internally and
are then simply instantiated when needed.

Greetings,
Norbert