Vertex::new has inconsistent constructors

[silverweed]

Currently, sfml::graphics::Vertex has several constructors:

    pub fn new<P: Into<Vector2f>>(position: P, color: Color, tex_coords: Vector2f) -> Self;
    pub fn with_pos<P: Into<Vector2f>>(position: P) -> Self;
    pub fn with_pos_color<P: Into<Vector2f>>(position: P, color: Color) -> Vertex;
    pub fn with_pos_coords<P: Into<Vector2f>>(position: P, tex_coords: Vector2f) -> Vertex;

I see a couple of problems with this interface:

1. why is position a generic type but the other ones aren't?
2. these constructors don't cover all cases (where is with_color?)

Problem 2. is minor (it's arguably rarely needed), but problem 1. is a bit annoying. If I want to interface with SFML from my own application - using a different Vector2 type - I cannot just do Vertex::new(v, color, v) if v is my Vector type (with impl Into<sfml::system::Vector2f>): I'm forced to convert it myself or it won't be accepted as the third argument. The same goes for color.

Moreover, having a trait bound on the generic type prevents these constructors to be const functions (today trait bounds on const fn are unstable).

So my proposal is:

1. either remove the genericity and only accept Vector2f - and in the process, make the functions const (my favourite solution), or
2. make every argument generic.

Of course proposal 1. breaks retrocompatibility, but I think it would be an acceptable tradeoff (sfml-rust is still 0.x after all).

[crumblingstatue]

1. why is position a generic type but the other ones aren't?

It's the most common argument, so I wanted the ability to write it concisely with just a tuple. I agree though that these might just be bloating the API unnecessarily, so I might remove them.

2. these constructors don't cover all cases (where is with_color?)

Is it really a common case that you want to make a vertex with a specific color, but you also don't want to explicitly specify that it's at (0.0, 0.0)?

I think I'll just remove all the generic Into parameters in the entire API. It's not that much of an inconvenience for the user to just call .into() explictly.