Improve PhantomData held by curve adaptors

[mweatherley]

Objective

The previous PhantomData instances were written somewhat lazily, so they were just things like PhantomData<T> for curves with an output type of T. This looks innocuous, but it unnecessarily constrains Send/Sync inference based on T. See here.

Solution

Switch to PhantomData of the form PhantomData<fn() -> T> for most of these adaptors. Since they only have a functional relationship to T (i.e. it shows up in the return type of trait methods), this is more accurate.

Testing

Tested by compiling Bevy.

[mweatherley]

I'm actually still a little bit unsure about MapCurve specifically. My reasoning was that it should behave like it owns a fn() -> S since it actually owns a curve with that output type; the fn(S) -> T phantom type looks reasonable but is also just going to be redundant in all real cases, because F: Fn(S) -> T whenever the struct is a curve (so, for instance, it could literally be a function pointer fn(S) -> T).

[MrGVSV]

My brain struggles so hard with trying to understand variance, but this looks right to me

[MrGVSV]

I'm actually still a little bit unsure about MapCurve specifically. My reasoning was that it should behave like it owns a fn() -> S since it actually owns a curve with that output type; the fn(S) -> T phantom type looks reasonable but is also just going to be redundant in all real cases, because F: Fn(S) -> T whenever the struct is a curve (so, for instance, it could literally be a function pointer fn(S) -> T).

When would MapCurve not be a curve? Is there a reason F isn't defined with the Fn(S) -> T bound?

[mweatherley]

When would MapCurve not be a curve? Is there a reason F isn't defined with the Fn(S) -> T bound?

It's often regarded as good practice not to include trait bounds on struct definitions unless they are required for the struct itself to make sense (e.g. by using associated types in fields). (If anything, this helps avoid needless duplication of trait bounds, but there are other reasons as well.)