Design By Contract

[KingOfThePirates]

As of right now, this discussion is expected to be super abstract.

Rust is a beautiful language because it is modern and built with common sense. Though it still lacks features that no modern language should. This discussion is only for one of those features. We are almost post-1.0, and, around that time, we should be thinking about how DBC, one of the most useful tools a programmer could use, should be used in Rust.

The only thing we have to worry about right now is when to actually have this discussion. It should be soon, but soon might mean many months from now.

• Should we wait for a certain feature to come out first? Which feature? Wait for more features, too?
• What else is needed or wanted to be done before we get into a DBC discussion?
• Should only conventions work it? What would they be? Should syntax for DBC exist?

So, when do you think official Rust-supported DBC solutions should be discussed?

[gsingh93]

I don't know much about this, but is this related: https://github.com/nrc/libhoare

Also, we're not post-1.0 yet :)

[KingOfThePirates]

The beta is not considered post-1.0?

[gsingh93]

Post 1.0 is after May 15th, when the real 1.0 is out.

[arielb1]

DBC looks like one of these things that should be a syntax extension.

[DiamondLovesYou]

@arielb1 I disagree. Syntax extensions have no access to type resolved results. I believe what one would actually want would be a compiler plugin.

[gsingh93]

@DiamondLovesYou I thought syntax extensions and compiler plugins were the same thing. Can you give an example of each?

[KingOfThePirates]

@gsingh93 I edited the tense in the original post.

@DiamondLovesYou I would also like an example of each.

[nrc]

@DiamondLovesYou what do you want type information for?

As it stands at the moment, there are many things which are compiler plugins - these include procedural macros (aka syntax extensions), pluggable lints, and pluggable llvm passes. We also expose an API to the compiler to allow building custom compilers which have access to type info and everything else the compiler does.

It seems to me that DBC can be (at least partially) implemented as a syntax extension (libhoare is a proof of concept of this). If there is lots of interest and use in a syntax extensions, then it might be worth experimenting with a custom compiler to support more DBC features which can't be implemented as a syntax extension. If that is successful, then I think we can discuss moving things into the compiler proper. As it stands I think any conversation about going straight to language features is not going to progress very far or quickly.

We should also have more powerful syntax extensions available in the medium term future, they should allow better syntax for things like DBC without having to have core language support.

[arielb1]

Anyway, what is design by contract? Rust has a powerful type system that already handles the 90% most popular propositions.

[arielb1]

I mean, the Rust type-system covers at least:

• parameter i can't be null (don't use an Option)
• parameter i and parameter j can't both be null (use an enum)
• parameter i must not be negative (use an unsigned type)
• parameter i may not be modified until so-and-so (use lifetimes)

And that's at least 80% of all propositions already.

[KingOfThePirates]

The purpose of Design By Contract is to make bugs almost non-exist at all times, thus very fast developing. The syntax for DBC is self-documenting, so you should almost never have a single comment in all your code, while at the same time, someone who has never taken even his or her first programming class can know exactly what your program does without any other documentation.

Design By Contract is a design concept for contractors to require that the world around them is in a certain state and for the world to be ensured by the contractor that the world will be in a specific state when the contractor's job is done. A contractor is a routine/method/procedure/function.

You can stop reading here, unless you want more info.

1. Caller of a routine calls the routine.
2. Require checks the routine's needs. If everything is as the caller was supposed to promise, move on. Else you get a compiler error that states which needs were not met.
3. The routine is now called
4. Ensure checks to make sure the routine did each and everything that it promised it would.
5. Goes back to the caller, like any other end of a called routine would.

An Eiffel example from The Pragmatic Programmer, page 114

sqrt: DOUBLE is
    -- Square root routine
require
    sqrt_arg_must_be_positive: Current >= 0;
--- ...
--- calculate square root here
--- ...
ensure
    ((Result*Result) - Current).abs <= epsilon*Current.abs;
  -- Result should be within error tolerance
end;

Though, this can be improved to be truly readable by fusing comments and what they are commenting into well-named routines. This, as a result, would eliminate repeating words, meaning your eyes should be able to glaze over just once and not waste time searching for something.

[gsingh93]

@KingOfThePirates Can you look at libhoare and see if that covers all the DBC constructs you need? If not, what's missing?

[KingOfThePirates]

I am sure it covers everything, except standards. I am not needing Rust to change anything at all.. for my personal projects. What I need, and of course everyone, is to have standards prepared for the future, when Rust is used by mainstream in businesses and such.

Plus Rust, being so early in development, why not have this powerful tool implemented in the language (I'd simply do it myself if I didn't start programming just since December)?

[gsingh93]

Plus Rust, being so early in development, why not have this powerful tool implemented in the language (I'd simply do it myself if I didn't start programming just since December)?

Because if we rush into things early, we're stuck with them forever. If this is a feature people want to use, they'll use the library, and if the library has enough use from the community, at that point it can be integrated into the language.

[KingOfThePirates]

I agree, which is part of the reason why I posted this. I wanted to know how many were interested. To me, who began programming with Code Complete, it seems silly to not implement these tools since we invented them. But I understand there are many who are unaware of concepts such as this one.

No matter what, there will be a language that is what I want, in the next decade or two, because if there isn't, I'll make it, but having it now would be awesome.

The reason why I am even using Rust as my first language while it is in early development is simply because I like it and its community. It isn't that bad that many of its members don't like every design concept that I like or as much as I like them. I still like this place so I'll stay here for awhile.

Since I'm new to programming, could you tell me why you think modern design concepts such as DBC are not simply in the standards of all coding?