View mode: basic / threaded / horizontal-split · Log in · Help
January 14, 2005
Assertion syntax
(Sorry for posting twice; I accidentally clicked "Reply Group")

While dumping some thoughts in code on the state of variables I found myself
typing 'loose' boolean expression:

  mindh[y][x][0] == -maxdh[y][x-1][1];

Now, wouldn't that be a cool syntax for assertions? No function call. It
totally fits into D's Design By Contract and it's very readable (I often
find myself wondering what value it was assert(x) aborts on).

Lionello.
January 15, 2005
Re: Assertion syntax
I'm against, because it is not searchable. The current assert can even 
be made a keyword in the editor, which makes it stand out - making it 
easy to distinguish as a secondary, or, depending on your point of view 
perhaps the primary part of the program.

Besides, your assert syntax leads itself to be mistyped as an assignment 
by people with pascalese background, and ocassionally even by the ones 
without - this common error is prevented inside if statements, and i 
think assert too.

-eye

Lionello Lunesu wrote:
> (Sorry for posting twice; I accidentally clicked "Reply Group")
> 
> While dumping some thoughts in code on the state of variables I found myself
> typing 'loose' boolean expression:
> 
>    mindh[y][x][0] == -maxdh[y][x-1][1];
> 
> Now, wouldn't that be a cool syntax for assertions? No function call. It
> totally fits into D's Design By Contract and it's very readable (I often
> find myself wondering what value it was assert(x) aborts on).
> 
> Lionello.
> 
>
January 16, 2005
Re: Assertion syntax
Lionello Lunesu wrote:

> (Sorry for posting twice; I accidentally clicked "Reply Group")
> 
> While dumping some thoughts in code on the state of variables I found
> myself typing 'loose' boolean expression:
> 
>    mindh[y][x][0] == -maxdh[y][x-1][1];
> 
> Now, wouldn't that be a cool syntax for assertions? No function call. It
> totally fits into D's Design By Contract and it's very readable (I often
> find myself wondering what value it was assert(x) aborts on).
> 
> Lionello.

Not a good idea: in general, the compiler cannot say whether an expression
has some side-effect or whether it can be safely dropped in -release mode.

Furthermore: statements that consist of an expression with the result being
dropped are perfectly legal in D. If you call a function that return a
bool, you might just not be interested in that result and only care about
its side-effect.
January 17, 2005
Re: Assertion syntax
"Ilya Minkov" <minkov@cs.tum.edu> wrote in message 
news:csc2vo$3m6$1@digitaldaemon.com...
> I'm against, because it is not searchable. The current assert can even be 
> made a keyword in the editor, which makes it stand out - making it easy to 
> distinguish as a secondary, or, depending on your point of view perhaps 
> the primary part of the program.

I want to refine my idea: allow the suggested syntax in the in{} and out{} 
blocks of contracts. Then you can find them easily.

> Besides, your assert syntax leads itself to be mistyped as an assignment 
> by people with pascalese background, and ocassionally even by the ones 
> without - this common error is prevented inside if statements, and i think 
> assert too.

You're right: "t.d(4): '=' does not give a boolean result"..

Thanks for your reply.

Lionello.
January 17, 2005
Re: Assertion syntax
> Not a good idea: in general, the compiler cannot say whether an expression
> has some side-effect or whether it can be safely dropped in -release mode.

Good point!
I'd refine my idea to allow the suggested syntax in the in{} and out{} 
scopes of a contract.

> Furthermore: statements that consist of an expression with the result 
> being
> dropped are perfectly legal in D. If you call a function that return a
> bool, you might just not be interested in that result and only care about
> its side-effect.

I guess one should already be careful not to include any statements with 
side-effects in the in- and out scope of a contract, right?

Lionello.
Top | Discussion index | About this forum | D home