Replace From implementation of SwapInterval that could panic with TryFrom

[antonilol]

fixes #1311

Unfortunately this is a breaking change, Rust automatically implements TryFrom for types that implement From, so just adding the TryFrom implementation will not work.

[Cobrand]

Doesn't seem a very useful breaking change to remove the From, although there is value is adding TryFrom. Could you please re-add From to call TryFrom?

[antonilol]

I can't, (see first comment), all From implementations come with a TryFrom implementation (same conversion, always returning Ok and Error is set to Infallible (empty type)), so they can't coexist (see https://doc.rust-lang.org/src/core/convert/mod.rs.html#802-815)

[Cobrand]

I see, so we can only do that when trait impl specialization is in stable. I think for now we could just add something that acts like try_from but doesn't use the trait TryFrom to avoid conflict, and then when it stabilized without breaking anything we can impl try_from directly.

[antonilol]

I see, so we can only do that when trait impl specialization is in stable.

This can take a while, and I don't expect that this will be specializable, because that would allow different logic for From and TryFrom, which to me is counterintuitive.

I think for now we could just add something that acts like try_from but doesn't use the trait TryFrom to avoid conflict, and then when it stabilized without breaking anything we can impl try_from directly.

We can add an inherent function SwapInterval::try_from(value: i32) -> Result<Self, SwapIntervalConversionError> and deprecate the From impl (the deprecation message will guide users to that function). This does sound as the best non-breaking approach to me.

The simplest way is 'just do a breaking change', it can be argued how many people use 1.into() or 0.into() given the context (spelling out SwapInterval::VSync or SwapInterval::Immediate is clearer).

[Cobrand]

We can add an inherent function SwapInterval::try_from(value: i32) -> Result<Self, SwapIntervalConversionError> and deprecate the From impl (the deprecation message will guide users to that function). This does sound as the best non-breaking approach to me.

I would prefer that. I know it's extremely minor but personally I hate when I update a library with a breaking change and it didn't even leave me 1 version of leeway to migrate to a new version using deprecation.

Plus, I really doubt that the trait TryFrom specifically is used by a lot of people, they just want a try_fromand try_into impl, but never are they going to use Box<dyn TryFrom<u32>> or fn example() -> impl TryFrom<u32>, so I don't really feel like there is a rush to implement TryFrom, especially if it breaks stuff.

[antonilol]

Apparently you can't deprecate a trait implementation in Rust, so I added a println! there, if you know of any ways to get a proper compile time deprecation warning, let me know!

[Cobrand]

Println in the console is really dirty, I would rather have nothing at runtime and just leave it as-is, but put the deprecation notice in a doc comment

[antonilol]

Rebased this one and my 2 other PRs

[antonilol]

@Cobrand is this ready for merge?