DIP83

[Andrei Alexandrescu via Digitalmars-d]

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