(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.

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.
> 
> 

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.

"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.

> 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.