Bug in readln interface ?
monarch_dodra
monarchdodra at gmail.com
Sun Jun 30 12:12:40 PDT 2013
The global readln has a signature that looks like this:
size_t readln(ref char[] buf, dchar terminator = '\n')
File.readln's is:
size_t readln(C)(ref C[] buf, dchar terminator = '\n')
if (isSomeChar!C && !is(C == enum))
You might think "Oh: Global readline isn't templated, it should".
Yes it should, but that's minor and trivial to fix.
The problem is that "C[]" can mean things like "const(char)[]",
which means, basically, "string". This means that the following
code is legal:
string reuseableBuffer; (!)
myFile.readln(reuseableBuffer); //Okey Dokey.
Note: This works perfectly fine, there is no illegal mutation or
anything. It's just that a brand new value is always assigned to
the (not so reuseable) reuseableBuffer slice.
The code handles this, but:
a) It Accepts code this makes little sense, and is most probably
an error that silently passes.
b) While the *code* accepts this, *reading it*, it feels more
like luck then explicitly handled.
c) This can be replaced just as well by:
c.1) "s = myFile.readln();"
c.2) "(s = myFile.readln()).size;" if you want the return value
----------------
So my question is: Do we *want* to keep this? Should we deprecate
it? I think we should deprecated it.
Thoughts?
PS: I got dibs on the fix :p
More information about the Digitalmars-d
mailing list