Hacker News Reader

Comment by gumby | Hacker News Reader

A pointer can be nullptr while a reference cannot so that would be a step backwards.

Also the “problem” you describe is not solved by your proposed “solution”. A const pointer can point to something that can be modified.

You can declare a pointer to a const object, or, you know, declare a const ref.

View on HN

Microsoft created SAL so you can annotate pointers to instruct the compiler to put up warnings or even errors for null required fields:

    _Success_(return)  //out parameters should be set if this returns true
    bool tryGetValue(
      _In_ Map const* map, //pointer is for input only and cannot be null
      _In_ char const* name,
      _Out_opt_ Data* value //pointer is for output and can be null
    );

If you pass null for _In_ params, the compiler will warn or error. You return true without setting the _out_opt_ parameters, the compiler will warn or error. You can pass null to _out_opt_, and the compiler will warn or error if the function body doesn't properly check if the parameter is null

Of course, that only works if you're passing a literal null. If you're passing a variable the compiler will not check anything, so this doesn't really solve the problem.

The annotation does need to be propagated backwards to callers and declarers - and there needs to be a way to "annotate" an existing pointer in the scopes where you've proven that it's not null - but that's better than having no annotation at all.

(Although this is something I'd 100% want C++ to do, and not with an annotation but with a very short operator or reserved word.)

[EDIT: Brainfarted in the last paragraph, read "const ref" as "ref"]

> A pointer can be nullptr while a reference cannot so that would be a step backwards.

Backwards from what? A reference can't be null, but it can still be invalid, which is a more common problem than forgetting to check for null-ness.

> You can declare a pointer to a const object,

Yes. I should have said that instead.

> , or, you know, declare a const ref.

That doesn't solve the original problem with references, though. I hate reading `foo (bar, baz)` and having to dig into the header to find out that bar or baz or both might be modified after the call to foo.

When reading code, I want to be able to skip over anything that does not modify the state of variables in the current scope.

Using references means that I have to know what every single call does. Using pointers exclusively, I can simply skip calls to functions with arguments that aren't pointers.

> Backwards from what? A reference can't be null, but it can still be invalid, which is a more common problem than forgetting to check for null-ness.

no, a reference cannot be invalid. If you are given an invalid reference (such as referring to an object after its lifetime ended, or referring to something that is not an object of the reference's type), then the fault lies on the caller. The callee cannot check the reference's validity, nor it is its responsibility to do so.

This is *very* different from the case of a pointer, where the caller is not at fault, typesystem wise, for giving a nullptr to a function accepting a pointer.

Increasing the probability of runtime errors to gain a little bit of readability at the caller's site is not a good tradeoff.

Reply on news.ycombinator.com