[lesbaker]

Looks like this is slides from a talk Walter Bright gave which has been posted to YouTube [1]. It helps with some missing context.

For example, I wondered why in the slides he felt implementing contract programming in D was a miss; it seemed like a strong selling point for the language. According to the talk (around 1:34:30), however, he felt that contract programming was relatively unpopular/unused in D and that "assert" covered most of the use cases for it.

[1] https://www.youtube.com/watch?v=p22MM1wc7xQ

[mamcx]

Contracts are interesting but I think to make it usefull 1) are ON on release! and 2) Become part of the docs.

One example:

     fun date(y:i32, m:i32, d:i32)
     {... code ...}

This scream for more context (and better param names!). With contracts:

     fun date(y:i32, m:i32, d:i32)
     assert
         y in 0..9999
         m in 1..12
         d in 1..31
     {... code ...}

But I need to see it in the docs, in the tooltips, etc. Now are useful!

[klipt]

Good old February 31.

[mamcx]

Nothing like a bug behind a safety feature :)

[elgenie]

That’s … not a bug.

A buggy assertion would be one that fires when the input is correct.

Assertions aren’t formal verifiers or replacements for a test suite.

[squarefoot]

Obligatory reference:)

https://www.youtube.com/watch?v=sVyRkl5qNb8

[masonic]

And year 0.

[mamcx]

I think that is why making the contract visible in the docs/intellisense or similar is valuable: You will understand more about the expectations of the code. Even if are incomplete or partial...

[mhd]

> (and better param names!)

And/or better param (sub-)types.

[p0nce]

I think it's because most of the time an assert can offer just about the same guarantees.

[WalterBright]

That's right.