On 2014-04-16, at 4:34, Daniel Micay <danielmi...@gmail.com> wrote:
> On 15/04/14 09:20 PM, Tommi wrote:
>> Disclaimer:
>> I don't know the current status of 'assert' macro, but for the duration of
>> this post I'll assume that it's going to change into a sanity-checking tool
>> and will get compiled away in release builds. I'll also assume that there
>> will be a macro called 'enforce' that will do the same thing as 'assert'
>> except that it won't disappear in release builds.
>>
>> Intro:
>> The 'unsafe' keyword represents the programmer's promise not to write any
>> memory-safety bugs in the block that follows it.
>>
>> Suggestion:
>> Let's add another keyword, say 'bugprone', that would represent the
>> programmer's promise not to write any non-memory-safety bugs in the block
>> that follows it. The effect would be that in such a block, all uses of the
>> 'enforce' macro would disappear.
>>
>> Motivating example:
>> fn foo(x: int, y: int) {
>> enforce!(x < y);
>> ...
>> }
>> It is documented that the function above has a prerequisite x < y and that
>> if it's satisfied, the function call is valid and won't cause a task
>> failure. When the programmer is in a position to know that the prerequisite
>> is satisfied, he could use this new keyword to make all 'enforce' statements
>> in 'foo' disappear:
>> bugprone { foo(x, y) }
>
> This would require compiling the functions again, and assumes the
> `enforce!()` macro is only used to handle safety critical preconditions.
>
Yes, the 'enforce' macro would be coupled with the 'bugprone' keyword, that's
the idea.
But, if it's too much complexity or code-bloat to make two versions of
functions, then perhaps I'll change my suggestion to something like D's input
contracts. That is, a programmer specifies that a function 'foo' has a certain
'precondition' function which checks the arguments passed to 'foo' and fails if
they're not valid. If the arguments passed to 'foo' are determined valid by the
'precondition' function, then the function 'foo' is called. Then, the
programmer can force the compiler to omit the call to the 'precondition'
function by wrapping the call to 'foo' in a 'bugprone' block. Something like:
fn foo(x: int, y: int) -> int
precondition {
x < y || fail!();
}
{
// function block ...
}
... and the following could be a shorthand for the above:
fn foo(x: int, y: int) -> int
precondition x < y {
// function block ...
}
Or, we can use the keyword 'in' instead of 'precondition' like D does, or 'if'.
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
