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

Ok I'll bite: it doesn't matter.

This DIP is additive. The problem with D is not that we don't have stuff in there, is most of the stuff in there are half backed. Adding more half baked things in there only makes things worse.

We don't have line number in stack traces, what does a better assert error message (that one can configure by code) will do  ? Worse, how is that consistent with the position that "Segfault are good enough with a debugger" and null by default reference types ?

There is no point in discussing the doorbell when the house has no window.

On 2016-01-14 15:28, deadalnix wrote:

> There is no point in discussing the doorbell when the house has no window.

+1. And AST macros would solve the problem (and a lot of other problems).

-- 
/Jacob Carlborg

On Thursday, 14 January 2016 at 19:51:37 UTC, Jacob Carlborg wrote:
> On 2016-01-14 15:28, deadalnix wrote:
>
>> There is no point in discussing the doorbell when the house has no window.
>
> +1. And AST macros would solve the problem (and a lot of other problems).

I used to think we didn't need AST macros until I hit the problems this DIP tries to address. After 2 years or so, I think you've finally convinced me Jacob ;)

Atila

On Thursday, 14 January 2016 at 14:28:05 UTC, deadalnix wrote:
> We don't have line number in stack traces

Huh? We dont have line numbers in stack traces? I have line numbers, I am using latest dmd, or are you talking about one of the other compilers?

On Thursday, 14 January 2016 at 14:28:05 UTC, deadalnix wrote:
> Ok I'll bite: it doesn't matter.
>
> This DIP is additive. The problem with D is not that we don't have stuff in there, is most of the stuff in there are half backed. Adding more half baked things in there only makes things worse.
>
> We don't have line number in stack traces, what does a better assert error message (that one can configure by code) will do  ? Worse, how is that consistent with the position that "Segfault are good enough with a debugger" and null by default reference types ?
>
> There is no point in discussing the doorbell when the house has no window.

True that. I think it's great to keep evolving the language and making it better, on the other hand, if D is to get serious adoption, then everything, especially the basics like debuggability, quality of codegen and compiler bugs will need to be solid. D as a language is already powerful enough to thrash the competition, this is why we love it. But the reason it's experiencing slow adoption, is because of tooling and general implementation quality, and the lower threshold of tolerance from the general population.

On Friday, 15 January 2016 at 11:11:41 UTC, Tofu Ninja wrote:
> On Thursday, 14 January 2016 at 14:28:05 UTC, deadalnix wrote:
>> We don't have line number in stack traces
>
> Huh? We dont have line numbers in stack traces? I have line numbers, I am using latest dmd, or are you talking about one of the other compilers?

Well I don't, both on OSX and linux, using the latest release. On linux I can do the addr2line dance, but on OSX I can't even do that as it require information that are gone once the program terminate.

On Friday, 15 January 2016 at 13:20:18 UTC, deadalnix wrote:
> Well I don't, both on OSX and linux, using the latest release. On linux I can do the addr2line dance, but on OSX I can't even do that as it require information that are gone once the program terminate.

Hmmm, I'm on windows so maybe that's it, pretty odd tho.

On Fri, 15 Jan 2016 13:20:18 +0000, deadalnix wrote:

> 
> Well I don't, both on OSX and linux, using the latest release. On linux I can do the addr2line dance, but on OSX I can't even do that as it require information that are gone once the program terminate.


Are you compiling with debug symbols on (-g)? You should get stacktraces on linux.

On 2016-01-15 11:21, Atila Neves wrote:

> I used to think we didn't need AST macros until I hit the problems this
> DIP tries to address. After 2 years or so, I think you've finally
> convinced me Jacob ;)

:D

-- 
/Jacob Carlborg