DIP 1009--Improve Contract Usability--Preliminary Review Round 1

MysticZach via Digitalmars-d digitalmars-d at puremagic.com
Wed Jun 21 12:18:18 PDT 2017


On Wednesday, 21 June 2017 at 18:04:07 UTC, Moritz Maxeiner wrote:
> On Wednesday, 21 June 2017 at 17:55:05 UTC, MysticZach wrote:
>> Question: If `assert` itself allowed a user-defined hook, what 
>> would the remaining justification be for decoupling `in` and 
>> `out` contracts from the `assert` logic?
>
> Because then you won't have normal asserts and contracts be 
> subject to different semantics?
> If I use a library, I may very well want to disable the 
> library's internal assert checks (because I have enough 
> experience that it's working properly), but keep it's contracts 
> alive, because my code is still shiny new and riddled with bugs.

Timon appears to think that the checking logic is more 
monolithic. From his reply above [1]:

"If [an alternative checking system is utilized], there should be 
a way to hook into the checking logic. This has nothing at all to 
do with contract syntax. asserts and contracts are coupled 
already, as in-contracts form a disjunction on override by 
catching AssertErrors."

So I'm hoping more people will weigh in on this issue. For 
example, how easy is it to separate a library's internal 
contracts from its external ones? Would you have to write 
internal contracts in a different way from the ones facing the 
user? How often is this distinction the one causing problems with 
productivity?

The way I'm thinking about it would be that if there were a 
pragma to turn off contracts in a particularly hot code path, 
then the rest of the program could remain safe, while the fast 
part was allowed to go as fast as possible, addressing the 
performance issue.

But regarding the information issue, what kind of error 
information is better delivered specifically through compiler 
knowledge of `in` and `out` contracts, versus what it would 
deliver in the same way via regular `assert`s? Or are all 
contracts basically just fancy sugar for asserts at the beginning 
and end of a function body? What can the compiler do with the 
extra information? What can it say to the user that the user 
wouldn't already be able to figure out if it were a regular 
assert?

[1] http://forum.dlang.org/post/oie2nt$emf$1@digitalmars.com


More information about the Digitalmars-d mailing list