Created attachment 126416 [details] Example demonstrating the Issue {=CONCAT(A1:A10&B1:B10)} is producing the expected output, but outputs the correct result to 10 consecutive cells of a column. So does also {=TEXTJOIN("||";TRUE();A1:A10&B1:B10)} independent of the expressions used on the first and secomd parameter positions.
May be a duplicate of bug 99625
(In reply to GerardF from comment #1) > May be a duplicate of bug 99625 May well be. Anyway the problem is described much clearer here, and is reported for the two related functions concerned which I suppose to use common code for the central part of their job. As the discussion under bug#99625 included irrelevant points and statements insufficiently preconceived (in specific comment #2). I would prefer to let this report live, and to start a clean discussion here not mentioning any obscure versions of Excel. There is a mandatory specification about "non-scalar evaluation aka array-evaluation" telling us under what conditions such evaluation has to take place and in what way it must be conducted. It is no doubt that a parameter position accepting an array shall also accept an expression evaluating into an array. This without changing the function result into an array if this was not specified explicitly. As neither CONCAT nor TEXTJOIN are specified at all in the relevant OASIS document OpenDocument-v1.2-part2.odt I cannot say if the array-accepting parameter should be restricted and in what way. I hope there is a specification of the functions in a reworked document I not yet know. If not, the functions should not become part of a release in advance of having created the specifications. PLEASE point me to the specifications if any! Unspecified functions are a nightmare we should lightheartedly leave to the competitors. A specification just saying "as Excel does" is the ultimate nightmare.
Created attachment 126823 [details] CONCAT vs. CONCATENATE Yes, this is the exact same report as 99625, except it includes CONCAT. There are no specifications, as these functions were introduced to be compatible with Excel's new functions, see bug 97831. I'd prefer to see minimal examples, like the one I'm attaching. C1 vs. C5, D1 vs. D5, obvious comparison (if my example is any good, I only have basic understanding of this).
(In reply to Aron Budea from comment #3) > Created attachment 126823 [details] > CONCAT vs. CONCATENATE > > Yes, this is the exact same report as 99625, except it includes CONCAT. (Not quite exact. See below.) > There are no specifications, as these functions were introduced to be > compatible with Excel's new functions, see bug 97831. Aiming at compatibility the first step should be thorough inspection of the pattern to imitate and tests with it, making sure to not miss something of relevance. Looking for a specification of the pattern may also be possible. The second step is to mould the results into rather plain language and to derive this way a specification for the imitation to be, regarding the changing environment. (Already existing mandatory specifications MUST persist this step.) Only the third step can then be the implementation of the new (imitated) functionality. These steps are urgently needed to be able to distinguish a bad implementation from a misunderstanding concerning the pattern. > I'd prefer to see minimal examples, like the one I'm attaching. ... I so do - within limits. The mentioned example only covers the case of a superfluous call to array evaluation. It demonstrates the bug, but not its severity. After all there are cases where array evaluation is relevant for the working of a formula. I tried to demonstrate such a case, much reduced again. OK. I used 10 rows where 3 or 4 might have done. Sorry!
(In reply to Wolfgang Jäger from comment #2) > PLEASE point me to the specifications if any! There is none. > Unspecified functions are a nightmare we should lightheartedly leave to the > competitors. > > A specification just saying "as Excel does" is the ultimate nightmare. Congratulations. You now know how developers feel.
*** This bug has been marked as a duplicate of bug 99625 ***