RazrFalcon/memmap2-rs

MSRV and edition

nyurik opened this issue · 5 comments

nyurik commented

Would it be worth it to update to 2021 and some later MSRV? 1.36 is 4 years old... seems rather dated

Since this does not impact dependencies at all (or rather keeping a low MSRV to henceforth edition can only improve the quality of life for dependent crates by broadening their choice of toolchain), are there any concrete changes you would like to make to the code base which are blocked on either MSRV or edition?

nyurik commented

@adamreichold thx for quick reply! I actually just posted a more relevant #92 -- which might have started using newer features of the language. In general, I do agree that legacy support is important, but it also introduces a hidden cost of "another papercut of not being able to use the newer feature that has been used everywhere else" - thus being a small detriment to contributions. For example, my IDE highlights that isize::MAX is deprecated, and I must make a mental effort to remember that it was deprecated only 3 (?) years ago, thus I should ignore IDEs warning.

which might have started using newer features of the language.

The fork is still at edition 2018 and I don't see any places where new language features would materially affect this code base.

In general, I do agree that legacy support is important, but it also introduces a hidden cost of "another papercut of not being able to use the newer feature that has been used everywhere else" - thus being a small detriment to contributions. For example, my IDE highlights that isize::MAX is deprecated, and I must make a mental effort to remember that it was deprecated only 3 (?) years ago, thus I should ignore IDEs warning.

This crate aims to be small wrapper around the underlying system calls and to be widely usable and hence I would personally prioritize the convenience of dependent crates over the convenience of working on this crate. It does not see a lot of churn and it is relatively simple by design.

For example, the mention deprecation of isize::MAX seems absolutely inconsequential to me compared to what the actual difficulties of working on this crate are, i.e. making sure to get requirements imposed by the system calls right on multiple platforms and architectures, especially keeping 32-bit architectures viable.

nyurik commented

thanks, those are fair points

As @adamreichold stated, there are absolutely no technical reasons to bump edition and MSRV.