Consider whether not_null<> would be better replaced with contracts

[neilmacintosh]

F.23 gives examples of using not_null<> to specify a nullness constraint on a parameter. However, a type that carries a not-nullness constraint is problematic...it is rare that a variable is never null for its entire lifetime. It is more commonly a constraint on the variable at a specific point in its life: usually before it is passed to or returned from a function.

So it seems as though nullness/nonnullness constraints are better expressed via a contract-specification mechanism (yes, we lack on today...but Expects/Ensures is a way to workaround that for now).

[cubbimew]

Using the type system to prove correctness seems to be more powerful than preconditions: would the future compilers be able to infer preconditions through nested function calls, without actually making them part of the type system?
I can say that some finance people certainly love not_null and similar little wrapper types that guarantee things by construction. There's also Dropbox with their nn<T>..

btw, this discussion will also affect I.12 with its not_null<zstring> (which by the way is a not-so-rare example of a pointer that is never null)

[nadiasvertex]

There is no reason why variables cannot be marked not_null for their entire
lifetime. This composes very well with an optional<> type. There is a lot
of evidence for the view that NULL is a bad idea and should be avoided as
much as possible.

See
http://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare

On Mon, Jan 25, 2016 at 2:33 PM Neil MacIntosh notifications@github.com
wrote:

F.23 gives examples of using not_null<> to specify a nullness constraint
on a parameter. However, a type that carries a not-nullness constraint is
problematic...it is rare that a variable is never null for its entire
lifetime. It is more commonly a constraint on the variable at a specific
point in its life: usually before it is passed to or returned from a
function.

So it seems as though nullness/nonnullness constraints are better
expressed via a contract-specification mechanism (yes, we lack on
today...but Expects/Ensures is a way to workaround that for now).

—
Reply to this email directly or view it on GitHub
#509.

[gdr-at-ms]

@nadiasvertex @cubbimew
I'm afraid you're missing the point.
Of course nobody believes dereferencing a null pointer, or letting a null pointer run amock is a good idea. The issue is what is an effective and scalable way of checking or enforcing non-null. Putting the check directly in the static type system is one way; it has its own downsides, some of which are semantics paradoxes, e.g. non_null<T> when T can be moved from, or ABI constraints.
Another approach is expressing the constraint in a softer, semi-static, semi-dynamic system, possibly coupled with analysis tools. Contracts offer such venue. Etiher way, the constraint is expressed. We are looking at design and engineering issues related to scalability, flexibility, and composition.

I don't actually believe that expressing the constaint in the type system is more powerful. It might be more constraining it terms of where it can be used, but not necessarily more powerful.

[nadiasvertex]

@gdr-at-ms I was not speaking against the not_null decorator, but rather in support of it. My feeling is that, since it is impossible to banish nullability from the language, variables should be forced to be not null by the type system as much as is reasonable. That is, I don't think that not_null should be banished. I think that it should be used as much as possible. I wish that it could become the default.

[tamaskenez]

Whether a parameter holds an integer value or not could also be checked with contracts (think of dynamically-typed languages). But it feels much better to have a dedicated int type. Same way not_null feels better, too.

It's true there are grey areas regarding not_null and move. I hope those can be solved without sacrificing the always-valid kind of types.

[Pazns]

As a young programmer, I don't understand some parts of the problem, especially the "not_null" decorator example.

How the heck can we enforce that our pointer is "not null" with a wrapper type ? What is happening if we can't allocate what we are trying to allocate, for example ?
If this is just a promise, then we could have something in the documentation about pointers there never being null and let the code part be clear of noise.

Does the type system really have to care about the meaning of the values he is supervising ?
For a pointer, nullptr is a valid address, and that's all he cares about.

[cubbimew]

How the heck can we enforce that our pointer is "not null" with a wrapper type ?

Like any type with an invariant, it has a constructor that enforces this guarantee, E.5 Let a constructor establish an invariant, and throw if it cannot
It would be useless if it were "just a promise", at least to people like me who use types this way.

[gdr-at-ms]

Well, it is all about promises.
The interesting question is what happens when we fail to keep our promises.