You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Removed APIs that were marked as deprecated a long time ago. Disabled
by default support for path construction, assignment and appending from
container types. Users can still enable this functionality by defining
BOOST_FILESYSTEM_DEPRECATED.
Updated docs, tests and examples accordingly.
<i>Function removed, use <code>create_directory(const path& to, const path& from)</code> instead (note the reversed order of arguments)</i></td>
320
-
</tr>
321
-
<tr>
322
-
<tdstyle="font-size: 10pt" valign="top">
323
-
<code>class directory_entry</code></td>
324
-
<tdstyle="font-size: 10pt" valign="top">
325
-
<code>filename()</code></td>
326
-
<tdstyle="font-size: 10pt" valign="top">
327
-
✔</td>
328
-
<tdstyle="font-size: 10pt" valign="top">
329
-
<i>Function removed, use </i><code>path().filename()</code><i> instead.</i></td>
330
-
</tr>
331
-
<tr>
332
-
<tdstyle="font-size: 10pt" valign="top">
333
-
<code>class directory_entry</code></td>
334
-
<tdstyle="font-size: 10pt" valign="top">
335
-
<code>leaf()</code></td>
336
-
<tdstyle="font-size: 10pt" valign="top">
337
-
✔</td>
338
-
<tdstyle="font-size: 10pt" valign="top">
339
-
<i>Function removed, use </i><code>path().filename()</code><i> instead.</i></td>
340
-
</tr>
341
-
<tr>
342
-
<tdstyle="font-size: 10pt" valign="top">
343
-
<code>class directory_entry</code></td>
344
-
<tdstyle="font-size: 10pt" valign="top">
345
-
<code>string()</code></td>
346
-
<tdstyle="font-size: 10pt" valign="top">
347
-
✔</td>
348
-
<tdstyle="font-size: 10pt" valign="top">
349
-
<i>Function removed, use </i><code>path().string()</code><i> instead.</i></td>
The header provides <code>filesystem_error</code>, <code>file_status</code>, <code>directory_entry</code>, <code>directory_iterator</code>, <code>recursive_directory_iterator</code> and associated enums and functions.</td>
391
-
<tdstyle="font-size: 10pt" valign="top">
392
-
✔</td>
393
-
<tdstyle="font-size: 10pt" valign="top">
394
-
<i>These components were moved to separate headers </i><code>exception.hpp</code><i>, </i><code>file_status.hpp</code><i> and </i><code>directory.hpp</code><i>.
395
-
The workaround is to include the new headers or </i><code>filesystem.hpp</code><i>. The new headers are still included by </i><code>operations.hpp</code><i> if
396
-
</i><code>BOOST_FILESYSTEM_NO_DEPRECATED</code><i> is not defined.</i></td>
397
-
</tr>
398
-
<tr>
399
-
<tdstyle="font-size: 10pt" valign="top">
400
-
<code>path_traits.hpp</code></td>
401
-
<tdstyle="font-size: 10pt" valign="top">
402
-
The header contains implementation details of class <code>path</code>.</td>
403
-
<tdstyle="font-size: 10pt" valign="top">
404
-
✔</td>
405
-
<tdstyle="font-size: 10pt" valign="top">
406
-
<i>The header is deprecated and should not be used in user's code. Unavailable if </i><code>BOOST_FILESYSTEM_NO_DEPRECATED</code><i> is defined and will be permanently removed in a future release.</i></td>
407
-
</tr>
408
-
<tr>
409
-
<tdstyle="font-size: 10pt" valign="top">
410
-
Macro definitions</td>
411
-
<tdstyle="font-size: 10pt" valign="top">
412
-
<code>BOOST_WINDOW_API</code></td>
413
-
<tdstyle="font-size: 10pt" valign="top">
414
-
</td>
415
-
<tdstyle="font-size: 10pt" valign="top">
416
-
<i>No longer supported; API selection is always automatic.</i></td>
417
-
</tr>
418
-
<tr>
419
-
<tdstyle="font-size: 10pt" valign="top">
420
-
Macro definitions</td>
421
-
<tdstyle="font-size: 10pt" valign="top">
422
-
<code>BOOST_POSIX_API</code></td>
423
-
<tdstyle="font-size: 10pt" valign="top">
424
-
</td>
425
-
<tdstyle="font-size: 10pt" valign="top">
426
-
<i>No longer supported; API selection is always automatic.</i></td>
427
-
</tr>
428
-
<tr>
429
-
<tdstyle="font-size: 10pt" valign="top">
430
-
Macro definitions</td>
431
-
<tdstyle="font-size: 10pt" valign="top">
432
-
<code>BOOST_WINDOW_PATH</code></td>
433
-
<tdstyle="font-size: 10pt" valign="top">
434
-
</td>
435
-
<tdstyle="font-size: 10pt" valign="top">
436
-
<i>No longer supported; native path format selection is always automatic.</i></td>
437
-
</tr>
438
-
<tr>
439
-
<tdstyle="font-size: 10pt" valign="top">
440
-
Macro definitions</td>
441
-
<tdstyle="font-size: 10pt" valign="top">
442
-
<code>BOOST_POSIX_PATH</code></td>
443
-
<tdstyle="font-size: 10pt" valign="top">
444
-
</td>
445
-
<tdstyle="font-size: 10pt" valign="top">
446
-
<i>No longer supported; native path format selection is always automatic.</i></td>
Why wasn't convenience.hpp issuing deprecation errors, if it were to be removed?
All symbols defined in the header were marked as deprecated. That the header itself wasn't was my omission, I guess, but there was no point in keeping an empty header after the symbols were removed.
Inspect is also now broken: boostorg/inspect#18 because it is using the now removed normalize. Is replacing with canoncial the generally correct solution?
Inspect is also now broken: boostorg/inspect#18 because it is using the now removed normalize. Is replacing with canoncial the generally correct solution?
p.normalize() is equivalent to p = p.lexically_normal().
canonical is different in that it resolves symlinks and therefore requires p to exist.
Is there a list with the removed APIs and their replacements? The deprecation warnings used to tell us that, but they have been removed now, so it's not easy to figure out what leaf or branch_path (or normalize) need to be changed to.
Maybe =delete-ing the functions would have been better as a transitory measure until everyone fixes them.
There's been years of deprecation warnings, that's enough of a transition period.
The suggested replacements were mentioned in the warnings and the docs up until now. Now these symbols no longer exist. Everyone who hasn't updated their code can either remain on an older Boost release, or use the information from the older release to update their code.
Looks like you don't even bother to read what I write.
The majority of code using these constructs is in maintenance mode. The original author has long stopped paying attention to it. There's been nobody to update it for years. The code breaks today, and someone needs to fix it, going by the compile errors alone. He has no other context.
My suggestions have already been given. If you delete the functions instead of removing them, the deprecation warnings will point to the suggested replacement in the compile errors.
Failing that, the documentation should have a section listing the suggested replacements.
Looks like you don't even bother to read what I write.
I did, but I disagreed with your reasoning.
The majority of code using these constructs is in maintenance mode. The original author has long stopped paying attention to it. There's been nobody to update it for years. The code breaks today, and someone needs to fix it, going by the compile errors alone. He has no other context.
Sure, but does that mean I can no longer remove deprecated code from Boost.Filesystem?
We've been though this, multiple times. Most recently, when we deprecated and removed support for C++03, regardless of the level of support of downstream libraries. And surely enough, someone was frustrated and had to go ahead and update those libraries, even if that meant only cleaning up their CI.
Ideally, the one who makes the change should make an effort to update the downstream within Boost. Honestly, I didn't think anyone was still using the deprecated Boost.Filesystem APIs, so I didn't check. I probably should have checked anyway, sorry about that. But on the other hand, as far as I understand, I'm not obliged do this either, especially given that there was a generous deprecation period.
If you delete the functions instead of removing them, the deprecation warnings will point to the suggested replacement in the compile errors.
If the function is deleted, there are no deprecation warnings. There's a compilation error that doesn't mention the replacement. At best, there's a comment nearby suggesting a replacement. And you can't = delete enums, for example.
But most of all, this effectively means extending the deprecation period, which I simply don't want. This deprecated code is a burden which makes maintenance even more complicated than it already is.
Failing that, the documentation should have a section listing the suggested replacements.
Ok, I can restore the documentation. Although I don't think it'll make a difference. I consider the moment when the deprecation warnings were introduced was the time when it was most needed, not now.
<source>: In function 'int main()':
<source>:7:6: error: use of deleted function 'void g()'
7 | g();
| ~^~
<source>:3:39: note: declared here
3 | [[deprecated("please use f()")]] void g() = delete;
|
But most of all, this effectively means extending the deprecation period, which I simply don't want.
By one release; these are now errors, so they must be addressed. Deprecation warnings can be ignored for decades if the only "consumer" of code is CI and other tooling where one doesn't pay attention to successful builds.
Ok, I can restore the documentation. Although I don't think it'll make a difference.
Maybe not; people do pay attention to release notes, though, so it can't hurt to have it linked there.
17 commit comments
pdimov commentedon Jan 14, 2024
This breaks quickbook:
What is the recommended replacement?
Why wasn't
convenience.hppissuing deprecation errors, if it were to be removed?pdimov commentedon Jan 14, 2024
Never mind, the include was unnecessary, as nothing from the header was being used (FILESYSTEM_NO_DEPRECATED seems to be already defined.)
pdimov commentedon Jan 14, 2024
FWIW, the other two breakages are in auto_index (which I fixed) and in Log :-)
Lastique commentedon Jan 14, 2024
All symbols defined in the header were marked as deprecated. That the header itself wasn't was my omission, I guess, but there was no point in keeping an empty header after the symbols were removed.
Lastique commentedon Jan 14, 2024
Thanks, will fix.
mborland commentedon Jan 18, 2024
Inspect is also now broken: boostorg/inspect#18 because it is using the now removed
normalize. Is replacing withcanoncialthe generally correct solution?Lastique commentedon Jan 18, 2024
p.normalize()is equivalent top = p.lexically_normal().canonicalis different in that it resolves symlinks and therefore requirespto exist.pdimov commentedon Jan 18, 2024
Is there a list with the removed APIs and their replacements? The deprecation warnings used to tell us that, but they have been removed now, so it's not easy to figure out what
leaforbranch_path(ornormalize) need to be changed to.Maybe =delete-ing the functions would have been better as a transitory measure until everyone fixes them.
Lastique commentedon Jan 18, 2024
There's been years of deprecation warnings, that's enough of a transition period.
The suggested replacements were mentioned in the warnings and the docs up until now. Now these symbols no longer exist. Everyone who hasn't updated their code can either remain on an older Boost release, or use the information from the older release to update their code.
pdimov commentedon Jan 18, 2024
As the person who had to "update their code", except that it was other people's code, I can tell you from experience that that's not very convenient.
In fact removing the documentation in the exact moment it's needed the most is more than inconvenient, it's actively hostile.
Lastique commentedon Jan 18, 2024
I can understand the frustration, but the line has to be drawn somewhere.
pdimov commentedon Jan 18, 2024
Sure, but you don't have to draw the line in the way that maximizes the frustration.
Lastique commentedon Jan 18, 2024
Someone will be frustrated anyway because for one reason or another didn't bother to update the code for years despite the warnings. Oh well.
Anyway, what do you suggest me to do?
pdimov commentedon Jan 18, 2024
Looks like you don't even bother to read what I write.
The majority of code using these constructs is in maintenance mode. The original author has long stopped paying attention to it. There's been nobody to update it for years. The code breaks today, and someone needs to fix it, going by the compile errors alone. He has no other context.
My suggestions have already been given. If you delete the functions instead of removing them, the deprecation warnings will point to the suggested replacement in the compile errors.
Failing that, the documentation should have a section listing the suggested replacements.
Lastique commentedon Jan 18, 2024
I did, but I disagreed with your reasoning.
Sure, but does that mean I can no longer remove deprecated code from Boost.Filesystem?
We've been though this, multiple times. Most recently, when we deprecated and removed support for C++03, regardless of the level of support of downstream libraries. And surely enough, someone was frustrated and had to go ahead and update those libraries, even if that meant only cleaning up their CI.
Ideally, the one who makes the change should make an effort to update the downstream within Boost. Honestly, I didn't think anyone was still using the deprecated Boost.Filesystem APIs, so I didn't check. I probably should have checked anyway, sorry about that. But on the other hand, as far as I understand, I'm not obliged do this either, especially given that there was a generous deprecation period.
If the function is deleted, there are no deprecation warnings. There's a compilation error that doesn't mention the replacement. At best, there's a comment nearby suggesting a replacement. And you can't
= deleteenums, for example.But most of all, this effectively means extending the deprecation period, which I simply don't want. This deprecated code is a burden which makes maintenance even more complicated than it already is.
Ok, I can restore the documentation. Although I don't think it'll make a difference. I consider the moment when the deprecation warnings were introduced was the time when it was most needed, not now.
pdimov commentedon Jan 18, 2024
You are right, there aren't. But at least the message includes the function declaration, which is good enough (and better than nothing.)
https://godbolt.org/z/3efssaKGW
By one release; these are now errors, so they must be addressed. Deprecation warnings can be ignored for decades if the only "consumer" of code is CI and other tooling where one doesn't pay attention to successful builds.
Maybe not; people do pay attention to release notes, though, so it can't hurt to have it linked there.
Lastique commentedon Jan 18, 2024
Not everyone upgrade to every Boost release. And a missing function or a deleted function are basically equivalent anyway.
I have updated the docs with the description of the removed features.