assert(condition[, message]) patch

[kris]

Sean Kelly wrote:
[snip]
> There's a popular argument connected to contract programming which says 
> that it makes no sense to test with contracts enabled and disable them 
> in the release code.  I'd prefer not to take sides here, but I do think 
> that in instances where the application should halt because a condition 
> has not been met, an assert should be used.  If the programmer would 
> prefer that the user not see file and line information, he can easily 
> catch the error in main, report it however he wants to, and then return.
> 
> That said, my real goal here is merely to make assert a bit more 
> flexible so users aren't inclined to roll their own error handling 
> routines simply because they want to provide context information. 

Amen.

I find it surprising that the dmd support code still makes it awkward to 
add file & line number info to all exceptions. Asserts are no less vague 
in this respect. One has to wonder if this is deliberate or not?

On the other hand, Ares has provided for optional Exception file & line 
ctor arguments for at least a year.

Seems quite clear that people *want* more flexible assert and exception 
reporting. It also seems clear that everyone will roll their own if it's 
not provided as basic functionality. I certainly would like to add it to 
library code, since I suspect most folk would appreciate having it there :)

Is there a contrary argument or position? I mean, is there some negative 
aspect of enabling (optional) better error reporting?