• Andrei Alexandrescu (46/46) Jan 14 2016 Here are a few comments about http://wiki.dlang.org/DIP83:
• deadalnix (12/12) Jan 14 2016 Ok I'll bite: it doesn't matter.
• Jacob Carlborg (4/5) Jan 14 2016 +1. And AST macros would solve the problem (and a lot of other problems)...
• Atila Neves (6/11) Jan 15 2016 I used to think we didn't need AST macros until I hit the
• Jacob Carlborg (4/7) Jan 15 2016 :D
• Tofu Ninja (4/5) Jan 15 2016 Huh? We dont have line numbers in stack traces? I have line
• deadalnix (5/10) Jan 15 2016 Well I don't, both on OSX and linux, using the latest release. On
• Tofu Ninja (2/6) Jan 15 2016 Hmmm, I'm on windows so maybe that's it, pretty odd tho.
• Yazan D (3/7) Jan 15 2016 Are you compiling with debug symbols on (-g)? You should get stacktraces...
• deadalnix (4/12) Jan 16 2016 Yes, with function mangled names and symbol instruction's
• rsw0x (3/14) Jan 15 2016 dmd generates stack traces on linux now
• =?UTF-8?B?TcOhcmNpbw==?= Martins (10/22) Jan 15 2016 True that. I think it's great to keep evolving the language and
• rsw0x (4/15) Jan 15 2016 I think what he was pointing out is that many D features are
• deadalnix (2/19) Jan 16 2016 Yes, that was the larger point.

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

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

deadalnix <deadalnix gmail.com> writes:

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.

Jacob Carlborg <doob me.com> writes:

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

Atila Neves <atila.neves gmail.com> writes:

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

Jacob Carlborg <doob me.com> writes:

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

Tofu Ninja <emmons0 purdue.edu> writes:

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?

deadalnix <deadalnix gmail.com> writes:

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.

Tofu Ninja <emmons0 purdue.edu> writes:

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.

Yazan D <invalid email.com> writes:

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.

deadalnix <deadalnix gmail.com> writes:

On Friday, 15 January 2016 at 15:06:00 UTC, Yazan D wrote:
 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.

Yes, with function mangled names and symbol instruction's 
address. And only if I link with -export-dynamic , which is 
disabled by default on ld (and, really, shouldn't be necessary).

rsw0x <anonymous anonymous.com> writes:

On Friday, 15 January 2016 at 13:20:18 UTC, deadalnix wrote:
 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.

dmd generates stack traces on linux now
I think it was either ldc or gdc that did before.

=?UTF-8?B?TcOhcmNpbw==?= Martins <marcioapm gmail.com> writes:

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.

rsw0x <anonymous anonymous.com> writes:

On Friday, 15 January 2016 at 11:58:19 UTC, Márcio Martins wrote:
 On Thursday, 14 January 2016 at 14:28:05 UTC, deadalnix wrote:
 [...]

 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.

I think what he was pointing out is that many D features are 
currently barely functioning or not working and adding more 
features is just a waste of time.

deadalnix <deadalnix gmail.com> writes:

On Saturday, 16 January 2016 at 03:00:33 UTC, rsw0x wrote:
 On Friday, 15 January 2016 at 11:58:19 UTC, Márcio Martins 
 wrote:
 On Thursday, 14 January 2016 at 14:28:05 UTC, deadalnix wrote:
 [...]

 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.

 I think what he was pointing out is that many D features are 
 currently barely functioning or not working and adding more 
 features is just a waste of time.

Yes, that was the larger point.