[Grep] update description to match problem-specifications, and make decision on output type
The instructions says Your task is to implement the `grep` function, which should read the contents of the specified files, find the lines that match the specified pattern and then output those lines as a single string.
By single string, i understand that if there are multiple lines matching the pattern, those lines should be concatenated to a single string.
However, at least in Rust, a test for multiple matches is written like this :
test_one_file_several_matches_no_flags(
pattern = "may",
flags = [],
files = ["midsummer_night.txt"],
expected = [
"Nor how it may concern my modesty,",
"But I beseech your grace that I may know",
"The worst that may befall me in this case,"
]
)
Where matching lines are not concatenated.
I created an issue in the meta repo https://github.com/exercism/problem-specifications/issues/1873 and it seems my understanding of the instructions is correct : found strings should be concatenated.
Now that https://github.com/exercism/problem-specifications/pull/1876 is merged, there is a new option for this issue: Update the description to match the new problem-specifications description, in which case the description no longer requires concatenating the strings.
In that case, since it's no longer required, we may make an independent decision on whether we want to concatenate them anyway, or instead leave them as they are. Both seem equally valid to me, in which case I think we can agree it's less work to leave them as they are, and that would be my suggestion.
This is one of the problems fixed by this PR: https://github.com/exercism/rust/pull/1549
Is action here still needed?
The exercise was updated with problem-specifications, so the instructions don't specify a single string anymore. The exercise stub also includes Result<Vec<String>, Error> in the function signature, which makes it immediately clear that a vector of lines should be returned. Anything else wouldn't pass the type checker. As there is no potential for confusion anymore, I don't think we should break existing solutions by changing the signature expected by the test suite.