The syntax .Return<type>(obj) to force the object to be copied and .Return<type&>(obj) to force the object to be captured by reference have been removed by #330 be caused it caused issues with the new implementation of .Return(obj), and because it was not a real documented feature (but more a by-product of the implementation), I supposed no one was relying on it.
[ ] Reintroduce back the support for .Return<type>(obj) and .Return<type&>(obj) to not break to much code with the new update, maybe mark them as deprecated.
[ ] Make .ReturnCapture(obj) available on any function (those that return a reference and those that does not) so it can be used as a default when the user ALWAYS want to capture the value of the object, regardless of the return type of the mocked function.
[ ] Add an equivalent to .ReturnCapture(obj) but that forces the capture of the object by reference, this feature already as its own issue (#200).
[ ] Extend the two functions mentioned above so they support the extra features of Return (e.g. .Return(obj1, obj2, ...), .Return(val_Times(5)), maybe more).
The syntax
.Return<type>(obj)to force the object to be copied and.Return<type&>(obj)to force the object to be captured by reference have been removed by #330 be caused it caused issues with the new implementation of.Return(obj), and because it was not a real documented feature (but more a by-product of the implementation), I supposed no one was relying on it.It turns out that some people use this feature (see https://github.com/eranpeer/FakeIt/issues/200#issuecomment-972461734 and https://github.com/eranpeer/FakeIt/pull/336#issuecomment-2108062764), not only to change the behavior of
.Return(obj), but also to have a consistent behavior, i.e. having.Return(obj)do the same thing regardless of if the mocked function return a reference or an object.What should be done:
.Return<type>(obj)and.Return<type&>(obj)to not break to much code with the new update, maybe mark them as deprecated..ReturnCapture(obj)available on any function (those that return a reference and those that does not) so it can be used as a default when the user ALWAYS want to capture the value of the object, regardless of the return type of the mocked function..ReturnCapture(obj)but that forces the capture of the object by reference, this feature already as its own issue (#200).Return(e.g..Return(obj1, obj2, ...),.Return(val_Times(5)), maybe more).