On Sat, 27 Jan 2018 17:12:25 +0000, kdevel wrote: > This is not a problem, because this is perfectly legal. The problem is > the wording of this phrase on the docs: > > | Also, do not use enforce inside of contracts (i.e. inside of in and > out blocks | and invariants), because they will be compiled out when > compiling with | -release. Use assert in contracts. > > Using assert *IN* contracts in -release mode is equally pointless.
... > | Also, do not use enforce inside of contracts (i.e. inside of in and > out blocks | and invariants), because they will be compiled out when > compiling with | -release. Use assert in contracts. > > to me. IMHO this advice is pointless. ... > Then please explain to me, in which respect the advice to "Use assert[s] > in contracs" makes sense if the contracts are to be compiled out. I > don't get it. I think I see what you mean; you interpret "use asserts, because enforce will be compiled out" to imply that asserts wouldn't be compiled out, correct? Since, in reality, both would be compiled out, it shouldn't matter what you use, so the docs shouldn't care. That makes sense. The documentation seems to assume the reader has certain expectations of assert and enforce[0], so each function expresses a different intention to the programmer; when I see `assert()` I expect those checks only in non- release mode; when I see `enforce()` I expect those checks regardless of the flags that have been set[1]. Placing `enforce` in a contract messes with that expectation. What language here would make more sense to you? Anything I can come up with is either awkward or pretty verbose. --Ryan [0]: The correct expectation, but that's not necessarily important when it's not explicitly described. [1]: So you can use enforce to validate user input, but never assert.
