Returning scanned values instead of passing by reference about scnlib

[eliaskosunen]

This had been under consideration in the initial design stages of the library, but I decided on pass-by-reference for the following reasons:

1. Consistent with scanf and std::cin

2. Consistent with {fmt}/std::format

Argument handling/type-erasure facilities from std::format could be utilized in the future.

3. Using tuples as return values in clunky (pre-C++17)

The library supports C++11 and 14. Without structured bindings, returning a tuple would, in my opinion, be worse than passing by reference.

int i;
scn::result<int> r;
std::tie(r, i) = scn::input<int>("{}");

This doesn't remove the problem of default-constructing the arguments before the call.

But I want to scan non-default-constructible values!

This would prevent us from scanning multiple values with a single call.

Consider this example:

auto stream = scn::make_stream("foo");

// Going to reach EOF mid-operation
auto [err, str, i] = scn::scan<std::string, int>(stream, "{} {}");
// err.error() == scn::error::end_of_stream
// str == "foo"
// i is default constructed

If a scanning operation of multiple values fails, the arguments that couldn't be read must be default-constructed.

This could be worked around of with the pass-by-reference API, by implementing a optional-like type, that only constructs the underlying non-default-constructible value on assignment. I cannot think of a way to go around this with a returning API.

// Note: this would need scn::scanner<std::optional<T>> to be specialized
std::optional<non_default_constructible> val(std::nullopt);
scn::input("{}", val); // val is only going to be assigned to if the scan succeeds

An additional advantage of the pass-by-reference API is the ability to have default values for scanned values in case of an error, because the value is not going to be modified in case of an error.

int i{42};
auto ret = scn::input("{}", i);
if (!ret) {
    assert(i == 42);
} else {
    // whatever we got from stdin
}

[eliaskosunen]

An alternative API, returning a std::tuple, is available on the branch return-api.

[eliaskosunen]

return-api-branch has been merged. The alternative API causes a ~5% slowdown, and requires C++17 to be any usable, but it's there.