Output parameters vs return values

[dimztimz]

My comments are mostly for the C++ proposal P1729. In the first revision the API used output parameters, similar to scanf and iostreams, but in the second revision it was changed to use return value. Now, the newer API might be more ergonomic (arguable), but it can be less performant, especially when reading strings.

Consider the following example:

std::string key;
int value;
for (...) {
    std::scan(some_input, "{} = {}", key, value);
}

versus

for (...) {
    auto result = std::scan<std::string, int>(some_input, "{} = {}")
}

The first example is more performant because it will reuse the same std::string object and it will avoid unnecesarry allocations. In the second example the std::string object will be constructed and destructed in each loop iteration, potentially allocating in each iteration. SSO saves something, but in the first example we save much more unnecessary allocations.

[TD22057]

I agree w/ this comment. IMO the v1 API was simpler to use, easier to understand, and easier to see how the format string tied to values. Converting our code to the new version has resulting in much longer and more confusing parse statements.

[dimztimz]

Ping, any comments about this? One should take into account the user feedback too, not only the LEWGI feedback. The API design of v1 is better using output parameters for the data and return value for the error. The only nitpicking can be done about the API for the error class.

Alternatively, the proposal can propose both APIs, the with output params and another with return vale.