<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 7/2/19 5:47 AM, Gregory Szorc wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAKQoGam+RwMnk9isgL8+cPkxnzYQfJumszZLFgMeFLvLuNiYaQ@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <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"
              moz-do-not-send="true">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>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
Mercurial-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Mercurial-devel@mercurial-scm.org">Mercurial-devel@mercurial-scm.org</a>
<a class="moz-txt-link-freetext" href="https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel">https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel</a></pre>
    </blockquote>
    <p>FYI, PyO3 seems "close" to compiling on stable. I don't know
      enough about the code base or the problem at hand (i.e. removing
      specialization), but they seem pretty confident:
      <a class="moz-txt-link-freetext" href="https://github.com/PyO3/pyo3/issues/210">https://github.com/PyO3/pyo3/issues/210</a>.</p>
    <p>I think we are all starting to agree that using the 2018 edition
      plus whatever version is the latest for Debian for now is good
      enough, until we get to a less experimental stage.<br>
    </p>
  </body>
</html>