opened
Christopher22
username_0
## Introduction
It's quite interesting to see how many rects there are in Piston: Some crates just use `[f32; 4]`, some `type Rect = [f32; 4]` and there are at least two independend implementations of common rect methods out there (in `PistonDevelopers/rect` and `PistonDevelopers/shapes`). 
These are just examples for a problem which seems huge from my point of view: We want to provide a beautiful "Game-Engine-Universe", but have no common types there, rather a Tower of Babel.

## Proposal
I think we need not the separated crates we have already, but just a single one: `PistonDevelopers/types`.
It may contains stuff from the following crates at a central place:
- PistonDevelopers/shapes
- PistonDevelopers/array
- PistonDevelopers/rect
- PistonDevelopers/float (for a common Scalar)
- PistonDevelopers/vecmath

**This would be the opportunity to build one common, well documentated and widely tested foundation for further developments.** All of these type are highly dependend on each other, therefore there should be together too.

To fulfill our philosophy of lightweightest solution we could use cargo features: Beside the default which covers all, crates could choose just the types they need.

What do you think of this? Im may be just a newbe in your universe, but it would be an honor to me to build such a project againt these "Tower of Babel" here.

Christopher
Improve types in Piston
issue
created
bvssvni
username_1
The shapes, array, rect libraries are not commonly used. They were made for convenience.

The float library is just a way to write generic code over floats. It was to get the ecosystem relatively stable since this functionality was removed from the standard library, moved to [num](https://crates.io/crates/num) and then broke a lot. Figured out that we only needed the traits for floats, so we made a library just for this.

`[f32; 4]` is commonly used, but would like some guidelines. I think you can come up with something here. An idea:

Use `Into<[f32; 4]>` everywhere in generic libraries, because then there is no need to pick an abstraction. All people have to do is implement `From<[f32; 4]>` and `Into<[f32; 4]>`.

The overall Piston philosophy is to keep abstractions small, make them optional if possible, and do as little as possible when the direction to go is uncertain. We have not tested an abstraction for rects yet, so this needs some thinking.
comment