Tracking issue for potentially useful features in future Rust versions

[notgull]

As of the time of writing, the MSRV for softbuffer is 1.64.0. As far as I can tell there is no MSRV policy, but the informal rule seems to be that the limit is Rust versions released up to seven months ago. This issue keeps track of features that may be useful to softbuffer, but cannot be used yet because we don't have the required Rust version.

• Nightly
  • Fallible allocation could be worked into the error enum to provide a condition for low-memory systems.
  • We implement some parts as what's essentially a try block, but as a closure that is immediately called. Example. It would be nice to replace those cases with a simple try block.
  • We use a Box to wrap SurfaceDispatch in order to keep the type size predictable. However, for low memory systems we could use the allocator_api feature to provide a custom allocator to reduce allocations.

Feel free to add more that I've missed.

[ids1024]

As of the time of writing, the MSRV for softbuffer is 1.64.0. As far as I can tell there is no MSRV policy, but the informal rule seems to be that the limit is Rust versions released up to seven months ago.

The current requirement is based on what raw-window-handle requires, and matches what winit targets. I think it generally makes sense for softbuffer to not have a higher Rust MSRV than winit, anyway.

(Is there any particular MSRV policy for winit/glutin/raw-window-handle either? If any of these projects had an MSRV policy, it would make sense for them to be in sync.)

But it's good to track Rust features like this anyway.

[madsmtm]

See https://github.com/rust-windowing/winit/issues/1075 for previous discussion on that.