<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 1, 2019 at 1:56 AM Raphaël Gomès <<a href="mailto:raphael.gomes@octobus.net">raphael.gomes@octobus.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">As more and more Rust makes its way into the Mercurial code base, the <br>
question of picking a minimum required version of Rust becomes more and <br>
more urgent. On the one hand, staying too up to date means breaking the <br>
install for some of our users, and staying too far behind means creating <br>
a technical debt that only gets worse over time.<br>
<br>
Many interesting changes have happened in Rust since the Oxidation Plan <br>
was introduced, like the 2018 edition and procedural macros:<br>
<br>
     - Opting in to the 2018 edition would be a clear benefit in terms <br>
of future proofing, new (nice to have) syntactical sugar <br>
notwithstanding. It also has a new non-lexical, non-AST based borrow <br>
checker that has fewer bugs(!) and allows us to write correct code that <br>
in some cases would have been rejected by the old one.<br>
     - Procedural macros would allow us to use the PyO3 crate which <br>
maintainers have expressed the clear goal of compiling on stable, which <br>
would help in code maintainability compared to rust-cpython.<br>
<br>
These are the two major features I can think of that would be clearly <br>
beneficial and that I think should matter in determining the target Rust <br>
version. This means that the absolute oldest rustc version should be <br>
1.31.1, however picking the more recent 1.34.2 would be preferable as it <br>
is of course newer, but still packaged in Debian.<br>
<br>
I can volunteer to write the patch that will port the current 2015 <br>
edition code to 2018 and pin down the Rust version. I've talked to <br>
gracinet, who is currently the only other contributor writing major Rust <br>
patches, and he would be fine (could I say thrilled?) with adapting his <br>
newer code to the 2018 edition after said patch lands.<br></blockquote><div><br></div><div>I think targeting >=1.31 makes sense in order to get the 2018 edition. I fully support requiring the 2018 edition.</div><div><br></div><div>There are some compelling enhancements in >=1.32 that would be nice to use. But I don't feel as strongly about requiring their usage. In targeting something that is less than the minimal version for the 2018 edition, we do undermine the Rust edition philosophy a bit. But as Yuya said, Rust support is still not stable, so there is some room to more aggressively adopt Rust releases.</div><div><br></div><div>I agree with Yuya that targeting whatever Debian is packaging is a good move, as Debian packages tend to impacts a large portion of the Linux user base.</div><div><br></div><div>I would absolutely love to move to PyO3. But until they stop requiring Nightly, I'm opposed to the change. Until then, I guess we'll have to deal with Rust code that looks like Python C code for the time being. All the more incentive to minimize the amount of Rust code in the Python/C interop layer and focus on writing as much functionality in "pure" Rust as possible.<br></div></div></div>