Code change:
Functional programming is all about creating and using non-mutating functions. <del> The last challenge introduced the `concat` method as a way to combine arrays into a new one without mutating the original arrays. Compare `concat` to the `push` method. `push` adds an item to the end of the same array it is called on, which mutates that array. Here's an example: </del> <ins> The last challenge introduced the `concat` method as a way to merge arrays into a new array without mutating the original arrays. Compare `concat` to the `push` method. `push` adds items to the end of the same array it is called on, which mutates that array. Here's an example: </ins> ```js const arr = [1, 2, 3]; <del> arr.push([4, 5, 6]); </del> <ins> arr.push(4, 5, 6); </ins> ``` <del> `arr` would have a modified value of `[1, 2, 3, [4, 5, 6]]`, which is not the functional programming way. </del> <ins> `arr` would have a modified value of `[1, 2, 3, 4, 5, 6]`, which is not the functional programming way. </ins> <del> `concat` offers a way to add new items to the end of an array without any mutating side effects. </del> <ins> `concat` offers a way to merge new items to the end of an array without any mutating side effects. </ins> # --instructions-- <del> Change the `nonMutatingPush` function so it uses `concat` to add `newItem` to the end of `original` instead of `push`. The function should return an array. </del> <ins> Change the `nonMutatingPush` function so it uses `concat` to merge `newItem` to the end of `original` without mutating `original` or `newItem` arrays. The function should return an array. </ins> # --hints--

Related discussion:
text: And since merging two arrays is taught in the previous lesson, I think the goal of this lesson is to replicate the behaviour of push using concat. In that case, my suggestion would be: "Change the nonMutatingPush function so it uses concat to replicate the behaviour of push without altering the first and second arrays".
I think we need to be careful. The intended behavior is better. We don't want the users to concat a reference to the second array.
! you need to assign (newItem) to a new variable and return it
As far as I can see the idea here is the user should create a function that behaves like , but it returns a new array instead of modifying the array it's called on. That function can be implemented as follows This replicates as closely as possible, so that if I in the same way as if I used push So, the main issue is that both the solution and the final test need updating. Also wording, should help guide users down the right path.
If we want users to learn a "non mutating push", I think its better that the solution not provide an avenue to mutate the original arrays. I think the current intended solution is fine but the wording describing it isn't quite accurate.
I think it would be better to compare:
IMHO, it is necessary either to change the expected solution or the wording of the task. For example: P.S.: It seems to me that it is better to change the expected solution (based on the previously described behavior of the push method)
I wouldn't change the expected behavior.. If we change the expected behavior, then this is no longer a non-mutating function. We should modify the description.
I agree with any of your solutions, but I did not understand - why would another solution cease to be a non-mutating function?
If you change the expected behavior, then if is an array, the output of this function can be used to mutate , as I explained above.
Thank you. I understand what you mean... - but then it looks like we are deliberately simplifying the task to meet the requirements. Maybe it's better to just replace the expected behavior with (for example)?
I don't see how this would be a simplification. The current solution works fine. Not changing the solution wouldn't make the task simpler - it would make it identical to what it is right now.