Can I change the way functions work?

[SapphireSpire]

When you pass a variable to a function in a function call, the function makes a copy of the variable so that any changes made to the value of the variable only effects the copy. It's called pass-by-value and it's the default behavior of functions in c++.

Not only is this function behavior non-intuitive, the copy functionality introduces some overhead that can seriously impact performance and the need to create a reference parameter in the function definition and then pass it a pointer is just all kinds of confusing and difficult to write and read.

What I want to do is change the default behavior to pass-by-reference, without the need to declare reference parameters or pass pointers as arguments in function calls. I could still make copies of the arguments inside the function and use the copies if I don't want to change the argument values.

[jonnin]

this is how the language works.
you can hide it, but you can't 'fix' it.

you can hide it by passing an object type that hides the pointer; you can for example wrap something in a pointer in a class and then overload all the operators to work on the dereferenced pointer value and such. It would still copy the wrapper in the function calls (a small copy, nothing there but a pointer), but the underlying data, being a pointer, would still modify the passed in real data values due to using the overloaded assignment operator, etc.

This is probably *increasing* your overhead, not *reducing* it, though. It makes the code "prettier" (opinions will vary on this!) but adds a useless wrapper overhead and makes the code that much weirder to understand by whoever is reading it. I don't see this as a good idea.

[mbozzi]

Can I change the way functions work?

No.

The primary advantage of the current design is that it encourages the creation of pure functions and code which provides a strong exception-safety guarantee. In general, such functions are easy to compose, think about, and verify relative to unsafe functions with side-effects. Further, the current design is the natural one for people authoring software C++ along with assembler or C; the pass-by-value semantics is fundamental to both C and most common ABIs.

Not to add that references are significantly more complicated and subtle than values and even pointers; they're quite prone to introducing subtle lifetime issues in ways that values aren't.

Let's do a comparison:

int foo(int x)  { return x += 1; } // vs.
int foo(int& x) { return x += 1; }

Are you really telling me that either form is non-intuitive?

If the function should mutate its argument, bind it to a mutable reference. If the argument is expensive to copy and shouldn't be modified, bind the argument to a constant reference. It's not difficult, nor expensive.

@jonnin
std::reference_wrapper? Is used for storing reference-like objects in containers.

[jonnin]

new to me, so many things to see...
not knowing that one, I was saying do it by hand, but same idea.

And still seems like a bad idea, confusing to readers and excessive overhead (in the OP's use-case).

[SapphireSpire]

Pure functions are appropriate if all you want to do is math. But functions in c++ do a lot more than just math, most of which involves the deliberate use of side effects. Unreal Engine 4, for example, contains a ton of class functions that mutate their arguments and return no values. Exception safety is affected more by the choice of operations in a function and the order in which they occur than by side effects.

Pass by value is easy to write and read but it is NOT intuitive. If you hand me an empty box and I place a hamburger in it and give it back, you expect the box to contain a hamburger. If it's still empty, you would accuse me of shenanigans.

Pass by reference IS intuitive but difficult to write and read- the * and & are easy to miss or include by mistake. Itsy bitsy details like that are the greatest source of bugs.

[keskiverto]

Can I change the way functions work?

Yes, you can. It is really simple. Join the C++ standardization committee and convince all the experienced committee members that your intuition warrants this change to the language in its next official standard.

Read the first sentence of this: http://thbecker.net/articles/rvalue_references/section_04.html

[mbozzi]

Pure functions are appropriate if all you want to do is math.

The premise of your first paragraph is wrong. There are a number of fundamental counterexamples in the standard library itself (e.g., iterators), not to mention other components (variant, transform, sort, reduce, hash, ...) and external libraries (Boost.Spirit, Ranges v3) which use declarative and functional programming idioms to great effect.

Exception safety is affected more by the choice of operations in a function and the order in which they occur than by side effects.

Functions without side effects rarely need to worry about exception-safety.
Functions with side effects often need to worry about exception-safety. For those functions with side effects, it's quite difficult to provide rollback semantics (called the "strong exception guarantee")
https://en.wikipedia.org/wiki/Exception_safety
Without either
a.) making a copy of the original mutable data; or
b.) never modifying the original data at all
Requiring an explicit copy just makes the current idioms less convenient and more error-prone. (See copy-and-swap, e.g.)

The * and & are easy to miss or include by mistake. Itsy bitsy details like that are the greatest source of bugs.

They are potentially a source of bugs. I'm not certain that details like these are "the greatest source of bugs"; In most cases static typing would prevent run-time errors, especially in a const-correct codebase.

Would it be preferable if the core language made such typos harder to miss? Perhaps.

#define REFERENCE &
void incf(int REFERENCE x) { x++; } 

As long as a way to pass arguments by value remains in the language, the only differences are merely cosmetic. It makes more sense for pass-by-value to remain the default for the reasons I outlined in my previous post.