Here are a few comments about http://wiki.dlang.org/DIP83:
* Meta: We continue to be shorthanded at both reviewing and implementing
DIPs. DIP83 has a few issues that are simple and obvious, and would be
easily fixed upon review by the community. After approval, it will be
difficult to find someone to carry the implementation.
* Overall: The proposal is a good start but needs serious work toward
making it a precise specification. Right now it is not ready to act as a
blueprint of an implementation, or be converted to a section of the
language reference.
By paragraph:
* Minor phrasing: "when flagged for in call to compiler" - the meaning
is understandable only after having read the entire document.
Suggestion: "Allow for assert to do pretty printing of its failing
expression when a specific command line flag is passed to the compiler."
* Why is this feature subject to a compiler flag? The document should
explain why, or just enable the feature regardless.
* Minor phrasing: "This extra, so called, pretty printing" -> "This
extra so-called pretty printing" or better yet "This additional pretty
printing".
* "give no hint" -> "gives no hint". I won't submit further proofreading
comments.
* The rationale mentions unary operators. However, those are unlikely to
be of use: -, +, ~, *. Additionally, ++ and -- are straight
unrecommended inside an assert. Only assert(!e) may be arguably
interesting, although I can't think of good examples. I suggest we drop
unary operators altogether.
* The proposal should enumerate what top-level BINOPs are considered.
For example, are the assignment operators part of the set? Probably not.
My understanding is the proposal has been written mainly with these in
mind: ==, !=, <, <=, >, >=. && is also interesting. || is only
interesting if more decomposition is done on its operands. "in" would be
great. Off the top of my head, I'm not sure about these: +, -, *, /, %,
^^, &, |, ^, <<, >>, >>>, ~. The point here is it needs to be clearly
stated which operators are allowed.
* I fail to see how "Non-Operator Lowering" could be useful. assert(e)
fails if e is zero or null. The only possible case would be the odd
overloading of opCast!bool, in which case the document should explain
and motivate that with examples.
* The section "Non-Equality Operator Lowering" should be demoted because
it's just an implementation note. At the level of this DIP, != is
treated as an operator of its own.
* The onAssertFailed example imports std.traits but we're here in
druntime. This illustrates a broader discussion - without std.conv and
generally Phobos, onAssertFailed will only have little capability to
format nice strings. I don't have a good idea on how to address this.
Andrei
