Skip to content

DIP1006: Apply feedback from review thread #64

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.

Sign up for GitHub

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

Merged
mdparker merged 1 commit into from
May 18, 2017
Merged

DIP1006: Apply feedback from review thread #64

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 10 additions & 0 deletions DIPs/DIP1006.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -69,12 +69,22 @@ For this reason, developers are often wary of disabling such safety features, ev
What can be viewed as an acceptable performance cost is up to the end user and the code base.
Any OOP-intensive code will want to get rid of `invariant` as a first step, while more function-oriented code might be more interested in disabling `in` / `out`.

#### Relationship with `-release` and `-debug`

In DMD, `-debug` just mean enabling `debug` blocks, so there is no overlap with `-contracts`'s proposed functionality.
On the other hand, `-release` disables all aforementioned contracts, and, in addition, disable "switch errors"
(compiler-generated `default` case in a switch statement are turned into HLT instruction instead of throwing a `SwitchError`).
As a result, using `-contracts` with `-release` is equivalent to just using `-release`.

#### Considered alternatives

The 4 values available to the user are voluntarily simple and hierarchical. It makes little sense to allow any contracts without enabling asserts.
It would be feasible to allow `invariant` without `in` and `out` contracts, or only `out` contracts, only `in` contracts, or some other combination.
Since providing all combinations would increase complexity, but doesn't yet provide an obvious advantage, it was left out of this proposal (but can be subject to another one).

While a higher granularity is not recommended by the DIP author, it was one of the most discussed point on the review thread,
with several people expression an interest in the feature.

Since this proposal was heavily motivated by the cost of invariants, an obvious alternative is to reduce said cost.
However, the cost of having `invariant` enabled will never be null for builds that do not use invariants at all, which is the real motivation for this feature.

Expand Down