3 ms·
> However, readability at the call site (e.g. Foo(&bar) might mutate bar, whereas Foo(bar) should not) is still considered more valuable in a large scale codeba
by jcelerier 8y ago
> However, readability at the call site (e.g. Foo(&bar) might mutate bar, whereas Foo(bar) should not) is still considered more valuable in a large scale codebase
but does it make it any more readable ? if you use the pointer anywhere else and have it as a variable then suddenly you don't distinguish anymore between a pointer and a reference. It would frankly make more sense to have empty `#define in` and `#define out` macros and make a small clang plug-in that checks correct usage in your codebase - e.g.
int foo(int x, const foobar& my_foobar, boo& my_boo);
foo(x, in fb, out b); // ok
foo(x, out fb, out b); // compile error
- coreytabaka 8y agoIn most cases the context provides enough information: void Baz(Bar*); void Baz(const Bar&); void Foo(Bar* mutable_bar) { Baz(*mutable_bar); // Not mutated. } void Foo(Bar* mutable_bar) { Baz(mutable_bar); // Possibly mutated. } void Foo(const Bar& bar) { Baz(bar); // Not mutated. } void Foo(const Bar& bar) { Baz(&bar); // Compiler error. } The rule doesn't perfectly eliminate ambiguity, but it does a pretty good job overall. The point is to address the general use cases with familiar constructs that work across multiple toolchains.