Hello, I have some doubts about working formattedRead with space chars.

Example:

import std : formattedRead, DateTime, stderr, each;

DateTime parseDT(string str)
{
    int d,mo,y, h,m,s;
    formattedRead!"%d/%d/%d %d:%d:%d"(str, d,mo,y, h,m,s);
    return DateTime(y,mo,d, h,m,s);
}

void tryParse(string s)
{
    try
    {
        auto dt = parseDT(s);
        stderr.writefln!"valid '%s': %s"(s, dt);
    }
    catch (Exception e)
        stderr.writefln!"INVALID '%s': %s"(s, e.msg);
}

void main()
{
    auto vs = [
        "",
        "1",
        "1/1",
        "1/1/1",
        "1/1/1 1",
        "1/1/1 1:1",
        "1/1/1 1:1:1",
	];
    vs.each!tryParse;
}

outputs:

INVALID '': 0 is not a valid month of the year.
INVALID '1': parseToFormatSpec: Cannot find character '/' in the input string.
INVALID '1/1': parseToFormatSpec: Cannot find character '/' in the input string.
valid '1/1/1': 0001-Jan-01 00:00:00 <<< see here
INVALID '1/1/1 1': parseToFormatSpec: Cannot find character ':' in the input string.
INVALID '1/1/1 1:1': parseToFormatSpec: Cannot find character ':' in the input string.
valid '1/1/1 1:1:1': 0001-Jan-01 01:01:01

Is space a special char for formattedRead and it simple stop parse without throwing exception if not found space (that represented in fmt string)?
Have formattedRead any other special chars?
Or it's bug?

On Friday, 9 April 2021 at 16:11:26 UTC, Oleg B wrote:

I think it's a bug:

The char 0x20 is meant to be skipped till end of the string or a parseable char in the format string by the function readUpToNextSpec().

If the function found a whitespace in the input string, it's fine and skipped as long there is another whitespace char. But if the input string range is already done, it also does just nothing anymore. For other chars if would throw the 'Cannot find character' exception.

But the source declared this as "backwards compatibility":

string s = " 1.2 3.4 ";
double x, y, z;
assert(formattedRead(s, " %s %s %s ", &x, &y, &z) == 2);
assert(s.empty);
assert(approxEqual(x, 1.2));
assert(approxEqual(y, 3.4));
assert(isNaN(z));

So it seems to be a desired behaviour.

On Friday, 9 April 2021 at 16:11:26 UTC, Oleg B wrote:

It's a (at least to me) known bug (I haven't taken the time to report it yet; found it a few days ago, when I reworked the docs). formattedRead treats space sometimes special and sometimes not, which (obviously) may lead to strange behavior, like it does here. If you like, you can report this one; I'll probably will care about it in a few weeks/months (I first want to fix the formattedWrite bugs and finish implementing formatting floating point numbers without calling snprintf.)

On Friday, 9 April 2021 at 16:39:30 UTC, Ali Çehreli wrote:

When using the stable docs you still should get, what you are used to. But I guess, you used the master docs and looked at formattedWrite where the information used to be.

Since about three weeks I'm on reworking completely the docs of std.format. Before that, the module has been split in several submodules (package, read, write, specs). Meanwhile I moved the docs you know from formattedWrite to package (but yet not reworked completely, because the review process takes some time and I try to verify everything I state in the new docs in the source code). For formattedRead and reading in general, the new docs are already finished. Feedback is welcome.