3 ms·

I didn't claim that's why they were added, I said that's what they allow you to express. > Pointers can be presumed in some code bases not to be null with null

I didn't claim that's why they were added, I said that's what they allow you to express. > Pointers can be presumed in some code bases not to be null with nullability being the unusual and documented scenario. Just because you can train your users to assume/document when nullability is allowed, doesn't make it a better option than using a language construct that would make it explicit.

Ferrotin 4y ago
You literally did say that, it’s what the meaning of your words is. Pointers are a better option because they make the mutability apparent at the call site. Codebases with that convention work great. There is no special training or documentation overhead involved.
- cpgxiii 4y ago
  Specifically, what I said was > C++ specifically gives you mutable references to express the desired behavior in these cases where "these cases" refers to the common case of (a) having a mutable argument, (b) which you want passed by reference, and (c) do not want to be nullable, that is exactly the semantics achieved by passing via mutable reference. I am not claiming this is why Stroustrup added them (his own explanation for why references were added is "References are useful for several things, but the direct reason I introduced them in C++ was to support operator overloading."), but that the language provides a construct which provides exactly for the desired behavior. > Pointers are a better option because they make the mutability apparent at the call site. At the first call site, yes (sometimes, see below). Not at any further calls. > Codebases with that convention work great. There is no special training or documentation overhead involved. As someone who works with a large codebase following this style, I beg to differ. Codebases with this convention are littered with ReturnType func(ParamType* param) { assert(param != nullptr); ... } because mutable-arguments-via-pointer has introduced undesired nullability, where the intended behavior could have been expressed more directly as ReturnType func(ParamType& param) { ... } and, it inevitably combines all three types of methods ReturnType func1(const ParamType* param) { if(param != nullptr) { ... } ReturnType func2(ParamType* param) { assert(param != nullptr); ... } ReturnType func3(ParamType* param) { if (param != nullptr) { ... } mingling nullability and mutability, none of which is obvious from func1(&foo); func2(&bar); func3(&baz); and you still end up needing documentation to figure out what's happening.

Ferrotin 4y ago

You literally did say that, it’s what the meaning of your words is. Pointers are a better option because they make the mutability apparent at the call site. Codebases with that convention work great. There is no special training or documentation overhead involved.

cpgxiii 4y ago
Specifically, what I said was > C++ specifically gives you mutable references to express the desired behavior in these cases where "these cases" refers to the common case of (a) having a mutable argument, (b) which you want passed by reference, and (c) do not want to be nullable, that is exactly the semantics achieved by passing via mutable reference. I am not claiming this is why Stroustrup added them (his own explanation for why references were added is "References are useful for several things, but the direct reason I introduced them in C++ was to support operator overloading."), but that the language provides a construct which provides exactly for the desired behavior. > Pointers are a better option because they make the mutability apparent at the call site. At the first call site, yes (sometimes, see below). Not at any further calls. > Codebases with that convention work great. There is no special training or documentation overhead involved. As someone who works with a large codebase following this style, I beg to differ. Codebases with this convention are littered with ReturnType func(ParamType* param) { assert(param != nullptr); ... } because mutable-arguments-via-pointer has introduced undesired nullability, where the intended behavior could have been expressed more directly as ReturnType func(ParamType& param) { ... } and, it inevitably combines all three types of methods ReturnType func1(const ParamType* param) { if(param != nullptr) { ... } ReturnType func2(ParamType* param) { assert(param != nullptr); ... } ReturnType func3(ParamType* param) { if (param != nullptr) { ... } mingling nullability and mutability, none of which is obvious from func1(&foo); func2(&bar); func3(&baz); and you still end up needing documentation to figure out what's happening.