Re: [boost] [Filesystem V3] Filesystem Version 3 beta 1 availablefor download and comment

Subject: Re: [boost] [Filesystem V3] Filesystem Version 3 beta 1 availablefor download and comment
From: Peter Dimov (pdimov_at_[hidden])
Date: 2010-02-18 13:39:54

Beman Dawes wrote:
> On Thu, Feb 18, 2010 at 10:35 AM, Stewart, Robert
> <Robert.Stewart_at_[hidden]> wrote:
>> You state that extension() returns the period to allow
>> distinguishing between an empty extension and no extension. That
>> seems wrong. Typical use cases for working with the extension will
>> require stripping the period before proceeding, so you push extra
>> work onto the client. Furthermore, I can't think of a case in which
>> extension processing code would work differently when there is no
>> extension and when the extension is empty. The extension is an empty
>> string in both cases. Since you already provide has_extension() for
>> distinguishing that there is one, extension() should return an empty
>> string when nothing follows the period.
>
> IIRC, that was Volodya's original design and I can't recall anyone
> ever complaining about it. True, we didn't have the has_extension()
> function, but still, I hate to break existing code. Does anyone else
> have a strong opinion?

It is the right design to retain the period, IMO, and most "get extension" 
functions do so, even on Windows, where there is no difference between "foo" 
and "foo." when actually used to refer to a file. See for example

http://msdn.microsoft.com/en-us/library/e737s6tf%28VS.100%29.aspx

On POSIX, it's even more important to retain the period, because "foo" and 
"foo." refer to different files.

There are two main reasons to retain the period. First, client code may wish 
to distinguish between "" and "." as extensions, in order to, for example, 
append a default extension only in the "" case, where one is not supplied. 
Second, and this also applies to retaining the trailing slash in the 
directory name, to provide the ability to reconstruct the original path by 
concatenating its elements (directory, name, extension).

>> change_extension() requires that the client prepend a period to the
>> new extension string. Why is that necessary? I can imagine several
>> use cases in which the extension would be found without a leading
>> period. The client code would then have to prepend a period to use
>> change_extension(). Also, if you change extension() as I note above,
>> then it will return the right value for change_extension()'s second
>> argument.
>
> Again, I'm concerned about breaking existing code. I'm willing to do
> that for V3, but only if I become convinced it results in a real and
> noticeable improvement.

This is also the correct design, for consistency with the above. Changing 
the extension to "" and "." are different operations. Again, existing 
practice requires the dot even on Windows, see for example

http://delphi.about.com/library/rtl/blrtlChangeFileExt.htm