4 ms·
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
by lesbaker 7y ago
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 https://www.youtube.com/watch?v=p22MM1wc7xQ
- mamcx 7y agoContracts 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 7y agoGood old February 31.
- mamcx 7y agoNothing like a bug behind a safety feature :)
- elgenie 7y agoThat’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 7y agoObligatory reference:) https://www.youtube.com/watch?v=sVyRkl5qNb8 https://www.youtube.com/watch?v=sVyRkl5qNb8
- masonic 7y agoAnd year 0.
- mamcx 7y agoI 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 7y ago> (and better param names!) And/or better param (sub-)types.
- p0nce 7y agoI think it's because most of the time an assert can offer just about the same guarantees.
- WalterBright 7y agoThat's right.