added AngleKind and Angle

[dunmatt]

I've split AngleKind into its own submodule because I expect to re-use it for AngularVelocity and AngularAcceleration.

[coveralls]

Coverage increased (+0.03%) to 97.145% when pulling 4c090b6 on dunmatt:angularDevelopment into e70b0a4 on iliekturtles:master.

[dunmatt]

I'm not yet sold on this whole Kind idea. For this PR it seems like it makes sense, but as I'm writing the next one I'm running into problems compiling

        // How can I make this compile?
        fn test<A: a::Conversion<V>, T: t::Conversion<V>, R: v::Conversion<V>>() {
            Test::assert_approx_eq(&AngularVelocity::new::<R>(V::one()),
                &(Angle::new::<A>(V::one()) / Time::new::<T>(V::one())));
        }

due to the fact that Time isn't of AngleKind. I could create a copy of Time that has the right Kind, but that's just one quantity... it seems like Kinds are contagious. Is there some way I can tell the system that some types can be automatically changed into AngleKind?

[iliekturtles]

Thanks for another PR! Again I've just done a quick pass and will need to go through in more detail this week.

For the kind issue do you have the full error available? I think the issue may be that the Div impl leaves the result with a kind of uom::Kind and doesn't maintain the kind of the left-hand-side. This may be a tough problem to solve with the limits of specialization in Rust right now. e.g. we want ratio / time = time^-1 but angle / time = angular velocity.

[iliekturtles]

Maybe we should have a si::marker module for kinds to reside in?

[dunmatt]

I'll do it if you like. Left to my own devices I typically go by the rule of three.

Edit: Now that it inherits from uom::Kind the whole thing fits onto a single line, I'm starting to think it might be cleaner to just inline it.

[iliekturtles]

Can you also add into the commit message that this resolves #89. Just realized an issue already existed!

[dunmatt]

The full error for the kind issue is just that Div is expecting the same Kind on the left and the right, so &(Angle::new::<A>(V::one()) / Time::new::<T>(V::one())) by itself doesn't compile. I am worried that you're right, this may be tough to solve the way Kinds are currently implemented. If Rust had overloading it would be easy, I'd just define another implementation of division on a case by case basis.

Is it possible to define types that don't appear in the API docs? We could have the macros generate AngleKind versions of all the various things that might need it... although that would likely hurt compile times.

Another option that might not be too bad could be to relax the "SI purity" requirements and add "angle" as a dimension. That would have the perk of leading to a natural representation of SolidAngle as well (although that's not a thing that I personally have a use for at the moment).

Edit: as for tagging the issue, I'll do that when this is ready to squash.

[iliekturtles]

Sorry for the delays. Been a busy week and it's looking like I wont get time for a full detailed review until this weekend. The two most recent commits look good.

You can define items that don't appear in docs with #[doc(hidden)] and I'm hesitant for the same reasons as you. I'm going to spend some time thinking about this in more detail this weekend.

[iliekturtles]

Everything looks good! If you don't mind punting on what to do about Kind we can merge (please squash the commits and fix-up the message). If you would prefer to see the Kind question resolved first could you also add AngularVelocity to this PR so we have something to test with?

[iliekturtles]

Thanks again for the PR!

[dunmatt]

My pleasure, I'm stoked to finally be able to contribute to open source.