How, for example, would (PATHINFO_DIRNAME | PATHINFO_EXTENSION) or (PATHINFO_BASENAME | PATHINFO_FILENAME) be handled?

I'd be more inclined to write the test script as:


$path = '/dir/file.ext';
$newExt = '.ext2';

['dirname' => $dir, 'basename' => $file] = pathinfo($path);
$newPath = "$dir/$file$newExt";


But that may just be me.

So instead, how about a constant for the combined DIRNAME+FILENAME?

The same way BASENAME is FILENAME+EXTENSION? It would fill a hole in the matrix:

dirname/filename.extension
------- -------- *********   EXTENSION
------- ******** ---------   FILENAME
------- ******** *********   BASENAME
******* -------- ---------   DIRNAME
******* ******** ---------   ?[ROOTNAME? STEMNAME?]
(the remaining three dirname/filename/extension combinations aren't useful).

The output should follow the natural order of the file's path regardless of the order the bitmask was created. So (PATHINFO_DIRNAME | PATHINFO_EXTENSION) would be identical to the concatenation of pathinfo()'s matching indexes (['dirname'] . '/.' . ['extension']). The bitmask (PATHINFO_BASENAME | PATHINFO_FILENAME) would be normalized to just (PATHINFO_BASENAME) and return only the equivalent of pathinfo()'s (['basename']).

I now see that accepting a bitmask value will make things convoluted since:

PATHINFO_FILENAME | PATHINFO_EXTENSION -> same output as PATHINFO_BASENAME
PATHINFO_FILENAME | PATHINFO_BASENAME  -> normalized to PATHINFO_BASENAME
PATHINFO_DIRNAME  | PATHINFO_EXTENSION -> not useful

Introducing a new constant for the DIRNAME + FILENAME combination sounds like a better solution. However, coming up an appropriate name escapes me at the moment. To kick-start the options, consider these:

PATHINFO_FILEPATH
PATHINFO_FILENAMEPATH
PATHINFO_NO_EXTENSION
PATHINFO_EXTENSIONLESS
PATHINFO_DIRFILENAME

Personally I would go for DIRFILE or DIRFILENAME - a combination of the DIRNAME and FILENAME constants (and one that fits the current naming style) which should help users remember it.

I vote for PATHINFO_DIRFILENAME. I see it more consistent to the existing PATHINFO_ family of constants.

What is the next step? Unfortunately, I can't submit a patch since I do not know C. Also, what release would this feature target if approved?

The next step would be someone with C knowledge making a patch or pull request to add the functionality. It's not a particularly difficult change to implement: a new constant and the obvious edits to pathinfo() to support it. It's also subject to approval by the devs, of course, but I see no reason why something like this would be declined.

As for when, I can't really say. Features tend to come in minor releases but 7.3 hit feature freeze earlier this week for a scheduled release this December; releases are yearly so 7.4 (or 8.0) would be out end of 2019. But I don't think there is a strict rule about minor improvements like this so it's up to the devs and RMs whether this goes with 7.3.0, or 7.3.x/7.2.y/7.1.z, or waits until 7.4. Assuming the change was written and submitted soon, of course.

> Assuming the change was written and submitted soon, of course.

Or ever. :)