Simple scan of multiple values fails after one string value

[RazielXYZ]

scnlib 4.0.1 Take for example this simple test code:

#include <iostream>
#include <string>
#include <scn/scan.h>

int main()
{
    auto scanResult = scn::scan<std::string, std::string>(
        "TEST.32.bar", "TEST.{}.{}");

    if (!scanResult) {
        std::cout << scanResult.error().code() << " " << scanResult.error().msg() << "\n";
    }
}

This fails with code 3, Unexpected end of source. Changing the first argument to int makes it succeed, however adding any more arguments after the std::string goes back to failing. I've also seen it fail with "Argument list not exhausted" in some cases. Is reading more than one string out of an input, or anything else after reading a string, given well-defined separators, not supported in this manner?

[neel]

Any update on this issue ?

[oysstu]

Is this not related to https://github.com/eliaskosunen/scnlib/issues/121? Also mentioned in the FAQ https://www.scnlib.dev/faq.html#faq-1.

I think this question will keep coming up unless this is the default behavior.

[RazielXYZ]

Is this not related to #121? Also mentioned in the FAQ https://www.scnlib.dev/faq.html#faq-1.

I think this question will keep coming up unless this is the default behavior.

I see, it certainly does appear to be the same issue. I somehow didn't see that FAQ (or the other issue), apologies!

I do agree that maybe having that be the default behavior would make more sense with this style of format strings. Intuitively, I wouldn't necessarily expect a modern replacement to scanf to work the same way as scanf - we still have scanf if we want that, but the reason why one would want a modern replacement would be to have it be easier to use, more intuitive, safer and so on - and arguably having this be the way it works, rather than the scanf way, seems to be more intuitive (also shown by the number of people who have been expecting this to be the behavior and got bitten by the scanf behavior of parsing until space).

That said, I'm not sure how easy or nice this would be to implement - it would probably have to consider the character right after a {} to be part of the replacement field's pattern/options in a way, and that certainly feels odd/unexpected as far as the implementation standpoint goes, even though it would result in the expected/more intuitive behavior overall