Why does assert have to be implemented as an expression?

[Jon]

Does it really matter, considering that it is a void expression, that
assert is an expression instead of a statement?

 

[Ben Pfaff]

Does it really matter, considering that it is a void expression, that
assert is an expression instead of a statement?

Sure. A void expression can be incorporated into a larger
expression (e.g. with the comma operator). A statement cannot.

 

[Seebs]

Does it really matter, considering that it is a void expression, that
assert is an expression instead of a statement?

Probably, because you can use void expressions in at least a few contexts
in C:

x ? (assert(y), 1) : ...

More generally, the general rule in C is that things you could possibly
implement as expressions tend to be expressions. (C doesn't go as far in
this as, say, Ruby or Lua, but it's still pretty aggressive about it.)

-s

 

[Jon]

Sure. A void expression can be incorporated into a larger
expression (e.g. with the comma operator). A statement cannot.

I knew that. Do you have an example? I recently changed my assert macro
to be an expression and it DID clean things up nicely, but I think I
don't know the whole gist of the requirement and whether it's just a
corner case thing or a wildly-useful thing.

 

[Jon]

Probably, because you can use void expressions in at least a few
contexts in C:

x ? (assert(y), 1) : ...

Would you write code like that? I wouldn't. Have a better example?

More generally, the general rule in C is that things you could
possibly implement as expressions tend to be expressions.

And I'd go where to study that issue? Wikipedia? I do find it relevant
info, but, shouldn't it/that be knowledge?

(C doesn't
go as far in this as, say, Ruby or Lua, but it's still pretty
aggressive about it.)

Your stage. I'll review the draft paper/article if you want (as I will
ask many "dumb" questions).

 

[Seebs]

Would you write code like that?
No.

I wouldn't. Have a better example?

Not really, but I don't need one -- it's that way because people occasionally
use assert() in larger expressions, possibly because an assertion is only
relevant in some contexts.

And I'd go where to study that issue? Wikipedia? I do find it relevant
info, but, shouldn't it/that be knowledge?

Read a bunch of C code and think about the "Spirit of C", pretty much;
I guess you could read the Rationale for the standard.

Your stage. I'll review the draft paper/article if you want (as I will
ask many "dumb" questions).

If you'll pay me for my time, I care what you think I should write.

-s

 

[Jon]

Not really, but I don't need one -- it's that way because people
occasionally use assert() in larger expressions, possibly because an
assertion is only relevant in some contexts.


Read a bunch of C code and think about the "Spirit of C", pretty much;
I guess you could read the Rationale for the standard.


If you'll pay me for my time, I care what you think I should write.

You KNOW I won't consult to you after that tantrum.

 

[August Karlstrom]

Probably, because you can use void expressions in at least a few contexts
in C:

x ? (assert(y), 1) : ...

Oh no! Reminds me of a previous thread.


/August

 

[Ben Pfaff]

I knew that. Do you have an example? I recently changed my assert macro
to be an expression and it DID clean things up nicely, but I think I
don't know the whole gist of the requirement and whether it's just a
corner case thing or a wildly-useful thing.

I've never put an assertion into a larger expression in practice.

 

[Keith Thompson]

I've never put an assertion into a larger expression in practice.

But the fact that it can be used in an expression hasn't done you
any harm, has it? (I know you didn't say it had.)

assert() could have been written so it can only be used in a
statement context, or so it can be used in an expression context
(which of course means it can also be used as a statement by adding
a semicolon). It wasn't significantly more difficult to provide the
extra flexibility. If it could be used only in a statement context,
it wouldn't have caused any great harm, but neither would there be
any particular benefit in restricting it.

 

[Keith Thompson]

Which kind of statement did you have in mind?

Presumably an expression statement, consisting of an expression followed
by a semicolon, such as:

assert(x == 42);

And what do
you gain by making it a statement?

Convenience. (A related question would be what you would gain by
defining assert() so that it's only usable in a statement context;
the answer, as far as I can tell, is nothing.)

 

[Keith Thompson]

Presumably an expression statement, consisting of an expression followed
by a semicolon, such as:

assert(x == 42);


Convenience. (A related question would be what you would gain by
defining assert() so that it's only usable in a statement context;
the answer, as far as I can tell, is nothing.)

Sorry, I misunderstood the context. On re-reading, what I wrote makes
sense, but not as a response to what Peter wrote.

 

[Peter Nilsson]

Presumably an expression statement, consisting of an
expression followed by a semicolon, such as:

assert(x == 42);

I was imagining the OP wanted something like...

assert-statement:
assert expression ;

e.g.

assert x == 42;

Convenience.

What convenience?

 (A related question would be what you would gain by
defining assert() so that it's only usable in a
statement context; the answer, as far as I can tell,
is nothing.)

Even if it was defined that way, it's hard to imagine
why anyone would go to the trouble of implementing a
macro that enforces the rule!

 

[Eric Sosman]

I've never put an assertion into a larger expression in practice.

I have, but only in the depths of debugging:

for (i = 0; assert(i < N), haystack != needle; ++i)
;

Can't recall letting such a thing survive very long, though. If
the assert() was worth keeping, I'd rearrange the loop to give it
a separate existence, e.g.:

for (i = 0; ; ++i) {
assert(i < N);
if (haystack == needle)
break;
}