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