<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <p>Let's not tie these two issues together.</p>
    <p>The discussion clearly shows that the startsWith/endsWith(String)
      APIs are a trap that several people have fallen into. On that
      basis it should be deprecated. (Ordinarily, so as to emit a
      warning, and not for removal, so there won't be any compatibility
      issue.)</p>
    <p>There is also no requirement that a new API be introduced to
      replace any deprecated API. As the earlier discussion in the
      thread shows, both the path-based and the string-based use cases
      can be written using existing APIs, somewhat less conveniently and
      more verbosely; but these constructs are much more explicit and so
      are preferable to the APIs to be deprecated. The deprecation text
      should steer people toward the preferred constructs.<br>
    </p>
    <p>It would indeed be nice to have a file extension API, but this
      has been discussed several times and has run aground each time for
      a variety of reasons. Tying these together will hold up the
      deprecation for no good reason.</p>
    <p>Let's proceed with just the deprecation first and work on the
      file extension API separately.</p>
    <p>s'marks<br>
    </p>
    <div class="moz-cite-prefix">On 1/11/26 12:45 PM, David Alayachew
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:CAA9v-_N24Mv5+JabZQHjuyMZVBCHE4c-_y2ByQ6omxQwyYbD3A@mail.gmail.com">
      
      <div dir="ltr">
        <div class="gmail_default" style="font-family:monospace">Thanks
          for the response Anthony. Messages have been arriving
          out-of-order for me, so I didn't see yours at the time of me
          writing that message.</div>
        <div class="gmail_default" style="font-family:monospace"><br>
        </div>
        <div class="gmail_default" style="font-family:monospace">I think
          introducing the file extension API first, then gauging the
          need for a deprecation before doing it is fine. Sounds like
          then that we are universally agreed on the first step being to
          add the file extension API, yes?</div>
      </div>
      <br>
      <div class="gmail_quote gmail_quote_container">
        <div dir="ltr" class="gmail_attr">On Sun, Jan 11, 2026 at
          2:06 PM Anthony Vanelverdinghe <<a href="mailto:anthonyv.be@outlook.com" moz-do-not-send="true" class="moz-txt-link-freetext">anthonyv.be@outlook.com</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">
          <div>
            <p>I dissent. (Apparently my previous message wasn't clear.)<br>
              <br>
              The right order of things is to first introduce a file
              extension API. Then see if there's still complaints about
              `Path::endsWith(String)`. And only then, if there are,
              consider taking action.<br>
              <br>
              In my previous message I've already explained how these
              methods add real, tangible value and actually are
              intuitive.<br>
              (Again, ask developers to guess how `A::foo(B)` behaves,
              given that both `A::foo(A)` and `B::foo(B)` exist, and a
              large majority of them will intuitively guess it converts
              its `b` argument to an instance of `A` and passes it on to
              `A::foo(A)`. And their intuition would be correct in the
              case of `Path::endsWith(String)`. That being said, I'll be
              the first to admit that I've also made the mistake of
              attempting to use `Path::endsWith(String)` to test the
              file extension.)<br>
              <br>
              In hindsight, maybe `endsWithNames(String)` would've been
              a better choice, but hindsight is 20/20.<br>
              <br>
              Deprecating these methods now is premature. And
              deprecating them without replacement methods would result
              in way more complaints than there have ever been about
              `endsWith(String)`.<br>
              <br>
              Anthony</p>
            <div>On 1/11/2026 12:19 AM, David Alayachew wrote:<br>
            </div>
            <blockquote type="cite">
              <div dir="auto">Of course.
                <div dir="auto"><br>
                </div>
                <div dir="auto">I see lots of approvals and not really
                  any dissenters. Are we waiting for more responses? Or
                  is there anything we can do to kick start this?</div>
              </div>
              <br>
              <div class="gmail_quote">
                <div dir="ltr" class="gmail_attr">On Fri, Jan 9, 2026,
                  10:22 PM Brian Burkhalter <<a href="mailto:brian.burkhalter@oracle.com" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">brian.burkhalter@oracle.com</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">
                  <div> Thanks for the corroboration.<br id="m_-8914463101179384457m_-726007501657283544lineBreakAtBeginningOfMessage">
                    <div><br>
                      <blockquote type="cite">
                        <div>On Jan 8, 2026, at 1:50 PM, David Alayachew
                          <<a href="mailto:davidalayachew@gmail.com" rel="noreferrer" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">davidalayachew@gmail.com</a>>
                          wrote:</div>
                        <br>
                        <div><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline">Thanks
                            for reviving this.</span>
                          <div dir="auto" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">
                            <br>
                          </div>
                          <div dir="auto" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">
                            I am perfectly happy with the idea of
                            deprecating the
                            Path.{start,ends}With(String), and then only
                            add the file extension method. Originally, I
                            didn't know that new method was on the
                            table, so I suggested a rename. But the file
                            extension api feels like the superior
                            solution.</div>
                          <div dir="auto" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">
                            <br>
                          </div>
                          <div dir="auto" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">
                            10 times out of 10, if I am calling
                            endsWith, the only time I am not looking for
                            "whole" path elements is when I am looking
                            for a file extension. In every other
                            instance, the api does exactly what I expect
                            and want. And plus, something like looking
                            for a file extension is better off being
                            explicit.</div>
                        </div>
                      </blockquote>
                    </div>
                  </div>
                </blockquote>
              </div>
            </blockquote>
          </div>
        </blockquote>
      </div>
    </blockquote>
  </body>
</html>