3 ms·

You are just wrong here. References were not added to C++ for that reason. Pointers can be presumed in some code bases not to be null with nullability being th

You are just wrong here. References were not added to C++ for that reason. Pointers can be presumed in some code bases not to be null with nullability being the unusual and documented scenario.

kllrnohj 4y ago
> Pointers can be presumed in some code bases not to be null with nullability being the unusual and documented scenario. So document it regardless instead https://releases.llvm.org/3.8.0/tools/clang/docs/AttributeReference.html#nonnull https://releases.llvm.org/3.8.0/tools/clang/docs/AttributeRe...
cpgxiii 4y ago
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.

You are just wrong here. References were not added to C++ for that reason. Pointers can be presumed in some code bases not to be null with nullability being the unusual and documented scenario.

kllrnohj 4y ago

> Pointers can be presumed in some code bases not to be null with nullability being the unusual and documented scenario. So document it regardless instead https://releases.llvm.org/3.8.0/tools/clang/docs/AttributeReference.html#nonnull https://releases.llvm.org/3.8.0/tools/clang/docs/AttributeRe...

cpgxiii 4y ago

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.