-
Notifications
You must be signed in to change notification settings - Fork 5.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider whether not_null<> would be better replaced with contracts #509
Comments
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? btw, this discussion will also affect I.12 with its |
There is no reason why variables cannot be marked not_null for their entire See On Mon, Jan 25, 2016 at 2:33 PM Neil MacIntosh [email protected]
|
@nadiasvertex @cubbimew 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. |
@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. |
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 It's true there are grey areas regarding |
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 ? Does the type system really have to care about the meaning of the values he is supervising ? |
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 |
Well, it is all about promises. |
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).
The text was updated successfully, but these errors were encountered: