On Thu, 08 Sep 2011 09:05:35 -0400, Jacob Carlborg <[email protected]> wrote:
On 2011-09-08 13:04, Steven Schveighoffer wrote:
On Wed, 07 Sep 2011 03:27:43 -0400, Jacob Carlborg <[email protected]> wrote:
On 2011-09-06 19:39, Steven Schveighoffer wrote:
I like enums in terms of writing code that processes them, but in
terms
of calling functions with them, I mean look at a sample fstream
constructor in C++:
fstream ifs("filename.txt", ios_base::in | ios_base::out);
vs.
File("filename.txt", "r+"); // or "rw"
There's just no way you can think "rw" is less descriptive or
understandable than ios_base::in | ios_base::out.
-Steve
But "r+" is. And that's what I assume will be used when I see a file
opening function taking a string "mode" parameter. But if you say that
"rw" can/will be used instead than that's better.
Yes, I'll try to add "rw" and maybe some other letter combinations that
make sense in my next version.
But I think we still have to support "r+", even though it's esoteric,
because too much existing code already does this, and to not support it
would leave silently compiling bugs.
-Steve
Didn't you just say that you would check the string at compile time?
You can if you make it a template parameter. For example, my openFile
function that I wrote does this (in fact, I needed a template mode string
because the return type depends on it). The downside is you cannot pass a
runtime-generated string. I cannot actually think of any use cases for
that however.
In any case, the existing API does not use a template parameter, and we
have to try and break as little code as possible.
I wonder if there's a way to give the option of using a template parameter
or using a positional parameter without having two different symbol
names. hm...
openFile!(string modedefault = "r")(string filename, string mode =
modedefault) if (isValidOpenMode(modedefault))
{
if(!isValidOpenMode(mode))
throw new Exception("invalid file open mode: " ~ mode);
...
}
Would that work?
-Steve
