Deal. I can't make JBS Submissions, but if someone gets me a bug number, I can do it.
On Mon, Jan 12, 2026, 2:36 PM Stuart Marks <[email protected]> wrote: > Let's not tie these two issues together. > > 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.) > > 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. > > 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. > > Let's proceed with just the deprecation first and work on the file > extension API separately. > > s'marks > On 1/11/26 12:45 PM, David Alayachew wrote: > > 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. > > 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? > > On Sun, Jan 11, 2026 at 2:06 PM Anthony Vanelverdinghe < > [email protected]> wrote: > >> I dissent. (Apparently my previous message wasn't clear.) >> >> 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. >> >> In my previous message I've already explained how these methods add real, >> tangible value and actually are intuitive. >> (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.) >> >> In hindsight, maybe `endsWithNames(String)` would've been a better >> choice, but hindsight is 20/20. >> >> 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)`. >> >> Anthony >> On 1/11/2026 12:19 AM, David Alayachew wrote: >> >> Of course. >> >> 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? >> >> On Fri, Jan 9, 2026, 10:22 PM Brian Burkhalter < >> [email protected]> wrote: >> >>> Thanks for the corroboration. >>> >>> On Jan 8, 2026, at 1:50 PM, David Alayachew <[email protected]> >>> wrote: >>> >>> Thanks for reviving this. >>> >>> 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. >>> >>> 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. >>> >>>
