Sometime ago in a code-review (C++) I suggested to change the input argument from Path
type to Optional<Path>
, where the function has specific logic for unset path. It looks for me intuitively better, but the author appealed that Path::empty()
(empty path) method should semantically mean the same as unset Optional
.
My sole rational argument is that empty path may also be interpreted as the current working directory. But then I also thought that .
may be used as CWD as well.
What is a good default semantic for a cross-platform API path emptiness? E.g. .
may be not so common outside *nix OSes, or there are already some common semantics in any popular programming language.
.
must represent the current directory. Systems which handle it differently must still support.
as the current directory. – Justin Jan 14 at 17:11optional<path>
is very different frompath
, just like howoptional<string>
is very different fromstring
. It may be that the emptypath
is what you want, or it may be that it doesn't work for the case and you need anoptional
. It depends – Justin Jan 14 at 17:20doFooWithoutPath()
, which delegates the responsibility to the caller to call the correct method. I'm personally not fond of methods acceptingoptional
parameters (you know at the call site that you don't have a value), and I don't believePath::empty()
convey enough information in this case (why would an empty path means that it is unset?). – Vincent Savard Jan 15 at 15:54optional<path>
which isnullopt
if no file was found? Unless you check that value, you don't know if the path exists. And maybe your local code doesn't care; why should you not pass thatoptional
to others? – Nicol Bolas Jan 15 at 17:44