• Lionello Lunesu (8/8) Jan 14 2005 (Sorry for posting twice; I accidentally clicked "Reply Group")
• Ilya Minkov (10/24) Jan 15 2005 I'm against, because it is not searchable. The current assert can even
• Lionello Lunesu (7/15) Jan 17 2005 I want to refine my idea: allow the suggested syntax in the in{} and out...
• Norbert Nemec (7/19) Jan 16 2005 Not a good idea: in general, the compiler cannot say whether an expressi...
• Lionello Lunesu (6/13) Jan 17 2005 Good point!

"Lionello Lunesu" <lionello.lunesu crystalinter.remove.com> writes:

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

Ilya Minkov <minkov cs.tum.edu> writes:

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" <lionello.lunesu crystalinter.remove.com> writes:

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

Norbert Nemec <Norbert Nemec-online.de> writes:

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.

"Lionello Lunesu" <lionello.lunesu crystalinter.remove.com> writes:

 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.