On Monday, 27 August 2018 at 00:35:12 UTC, tide wrote:
> On Sunday, 26 August 2018 at 23:39:32 UTC, Manu wrote:
>> [...]
>
>
> It's not just VisualD, the debug info DMD produces just doesn't include things like global variables for some reason. I use VS Code to debug, I get around it by using -gc (which is now deprecated) and adding the variable to the watch list with the full name. It's a pain in the ass though.

Please see this SAoC https://forum.dlang.org/thread/wnjccfdfcptsfefafplr@forum.dlang.org

Kind regards
Andre

On 8/23/2018 8:53 PM, David Nadlinger wrote:
> On Thursday, 23 August 2018 at 23:27:51 UTC, Walter Bright wrote:
>> D deals with it via "chained exceptions", which is terrifyingly difficult to understand. If you believe it is understandable, just try to understand the various devious test cases in the test suite.
> 
> I don't think that assessment is accurate. Yes, I ported EH to a few new targets and wrote the first correct implementation of exception chaining for LDC, so I'm probably a couple of standard deviations off the average D user in that regard. But said average D user doesn't care about most of the nuances of this problem, like the details of implementing exception chaining without allocating too much, 

I find myself unable to explain the rationale of the behavior exhibited by the current chaining system. I dared not change it, as I presumed somebody surely built a store around it. It does not simply chain exceptions.


> or which exceptions take precedence in various intentionally twisted test cases.

The only documentation for this is the test suite itself, which does not have any documentation or rationale either, just tests.

I would appreciate it if you did document what it's supposed to do and why, as likely nobody else knows. Maybe if I understood why I'd be more forgiving of it :-)


> What they do care about is that the fact that an error has occurred is propagated sensibly in all cases without requiring extra attention, and that information as to the origin is not lost (hence chaining rather than just replacement). Heck, the fact that we still don't have default backtrace handlers that consistently work on all platforms is probably a much bigger problem than the minutiae of exception chaining behaviour.

I wish the minutiae was documented somewhere :-( as I care about the nuances of it, if only because I'm ultimately responsible for keeping it working correctly.


> All this is not to say that nothrow constructors aren't a good idea, though.

Not much point to debating that, as they're here to stay.

On Sunday, 26 August 2018 at 22:44:05 UTC, Walter Bright wrote:
> On 8/26/2018 8:43 AM, Chris wrote:
>> I wanted to get rid of autodecode and I even offered to test it on my string heavy code to see what breaks (and maybe write guidelines for the transition), but somehow the whole idea of getting rid of autodecode was silently abandoned. What more could I do?
>
> It's not silently abandoned. It will break just about every D program out there. I have a hard time with the idea that breakage of old code is inexcusable, so let's break every old program?

We all know that, but we also know that autodecode is a broken feature - which makes me shudder. So we are - once again - in the absurd situation where we have to say "If it's broke, don't fix it!" However, given the importance of string handling these days and given how basic a feature of any programming language it is, I'm surprised that nobody ever came up with a strategy to fix it. It was just said - ah, too dangerous, too complicated, let's leave bad enough alone. Do you think that companies that deal with languages would be happy to learn that D's string handling is a mess? That'd be an immediate show stopper. For these reasons I supported this particular breaking change.

It is unrealistic to assume that code will never break. But as I said in my post above, dmd should give guarantees of backward compatibility of at least N versions. Then we could be more relaxed about our code.

But breakage should be avoided where ever possible to begin with. To break code because you have to fix a badly implemented feature like partially constructed objects is just ridiculous.

You often say we have to report bugs etc., but a lot of D's issues are common sense issues that don't need massive community input, i.e. get the basics right, before adding new features for the heck of it, reliability, improved tools.

Do my suggestions really sound so unreasonable?

>> But what for was it introduced at all and why wasn't it thought through properly right from the start?
>
> Because nobody thought about that issue before. A lot of things only become apparent in hindsight.

QED. With this approach you do more harm than good. I have a bad feeling about the way things are going atm.

On Monday, 27 August 2018 at 01:15:49 UTC, Laeeth Isharc wrote:

It's simple, I went to GitLab to see the code of the tool, and I found the articles among the other projects of the author.

> I don't think he was very happy about the process around DIP1000 but I am not myself well placed to judge.

The whole story is pretty simple [1].

From my perspective, the request was to confine feature development into separate branch, to don't impact language adopters.

Pay-as-you-go all way down, also for the compiler/rt/phobos codebase itself.

> I definitely think a stable version with backfixes ported would be great if feasible.

The other way round: "keep it in sync with specification document, design set of acceptance tests and do all the development in a separate branch until is verified to both have desired semantics and don't cause any breakage in existing projects." [2]

I would like your opinion on that specific request, "keep it in sync with specification document" versus "bureaucracy" [3]

> I wonder if we are approaching the point where enterprise crowd-funding of missing features or capabilities in the ecosystem could make sense.  If you look at how Liran managed to find David Nadlinger to help him, it could just be in part a matter of lacking social organisation preventing the market addressing unfulfilled mutual coincidences of wants.  Lots of capable people would like to work full time programming in D.  Enough firms would like some improvements made.  If takes work to organise these things.  If I were a student I might be trying to see if there was an opportunity there.

That would great for the ecosystem, for the language... [4]

[1] https://forum.dlang.org/thread/o62rml$mju$1@digitalmars.com
[2] https://forum.dlang.org/post/o6fih1$2b14$1@digitalmars.com
[3] https://github.com/dlang/dmd/pull/8346
[4] https://forum.dlang.org/post/detxilaksggqsrdaogri@forum.dlang.org

/Paolo

On Monday, 27 August 2018 at 01:15:49 UTC, Laeeth Isharc wrote:

>
> I wonder if we are approaching the point where enterprise crowd-funding of missing features or capabilities in the ecosystem could make sense.  If you look at how Liran managed to find David Nadlinger to help him, it could just be in part a matter of lacking social organisation preventing the market addressing unfulfilled mutual coincidences of wants.  Lots of capable people would like to work full time programming in D.  Enough firms would like some improvements made.  If takes work to organise these things.  If I were a student I might be trying to see if there was an opportunity there.

I think D has reached the point where that'd make perfect sense. Move from the garage to a proper factory :)

On Monday, 27 August 2018 at 01:15:49 UTC, Laeeth Isharc wrote:
> There's no question from my perspective that D is much better than a year ago and unimaginably better from when I first picked it up in 2014.  One can't be serious suggesting that D isn't flourishing as far as adoption goes.

I agree, things got better since, despite of what's called "anarchy". We can see that the global objectives aimed at are reached, are worked on, despite of the many small 'out of context' contributions, which are however a necessary and a painful work required to fix all what's been done when development process was less good (i.e the technical debt accumulated when CI and reviews were less good).

On Monday, 27 August 2018 at 03:06:17 UTC, John Carter wrote:
>
> The last few years I have told myself (and anyone who doesn't back away fast enough) that "Constructors" do _not_ construct objects, they are "Name Binders." (Sort of like lisp's "let" macro)
>
> They bind instance variable names to pre-existing sub-objects.

One could say there is "storage" and "instantiation" of an object.
C++ binds the two in the same operation.

D does not, T.init must be a valid object. This is a major cultural change, though I believe the D way is superior on the efficiency stand-point (you can create large arrays of valid objects quite fast).

On Monday, 27 August 2018 at 11:02:14 UTC, Guillaume Piolat wrote:
> C++ binds the two in the same operation.
>
> D does not, T.init must be a valid object. This is a major cultural change, though I believe the D way is superior on the efficiency stand-point (you can create large arrays of valid objects quite fast).

I mean, then again, @disable this() ...

On Monday, 27 August 2018 at 09:36:43 UTC, Chris wrote:
> On Monday, 27 August 2018 at 01:15:49 UTC, Laeeth Isharc wrote:
>
>> [...]
>
> I think D has reached the point where that'd make perfect sense. Move from the garage to a proper factory :)

Who's going to pay for the factory?
-Alex

On Monday, 27 August 2018 at 07:34:37 UTC, Walter Bright wrote:
> On 8/23/2018 8:53 PM, David Nadlinger wrote:
>> On Thursday, 23 August 2018 at 23:27:51 UTC, Walter Bright wrote:
>>> D deals with it via "chained exceptions", which is terrifyingly difficult to understand. If you believe it is understandable, just try to understand the various devious test cases in the test suite.
>> 
>> I don't think that assessment is accurate. Yes, I ported EH to a few new targets and wrote the first correct implementation of exception chaining for LDC, so I'm probably a couple of standard deviations off the average D user in that regard. But said average D user doesn't care about most of the nuances of this problem, like the details of implementing exception chaining without allocating too much,
>
> I find myself unable to explain the rationale of the behavior exhibited by the current chaining system. I dared not change it, as I presumed somebody surely built a store around it. It does not simply chain exceptions.
>
>
>> or which exceptions take precedence in various intentionally twisted test cases.
>
> The only documentation for this is the test suite itself, which does not have any documentation or rationale either, just tests.
>
> I would appreciate it if you did document what it's supposed to do and why, as likely nobody else knows. Maybe if I understood why I'd be more forgiving of it :-)
>
>
>> What they do care about is that the fact that an error has occurred is propagated sensibly in all cases without requiring extra attention, and that information as to the origin is not lost (hence chaining rather than just replacement). Heck, the fact that we still don't have default backtrace handlers that consistently work on all platforms is probably a much bigger problem than the minutiae of exception chaining behaviour.
>
> I wish the minutiae was documented somewhere :-( as I care about the nuances of it, if only because I'm ultimately responsible for keeping it working correctly.


I can explain this, since I did the original implementation.
When I originally implemented this, I discovered that the idea of "chained exceptions" was hopeless naive. The idea was that while processing one exception, if you encounter a second one, and you chain them together. Then you get a third, fourth, etc.

The problem is that it's much more complicated than that. Each of the exceptions can be a chain of exceptions themselves. This means that you don't end up with a chain of exceptions, but rather a tree of exceptions. That's why there are those really nasty test cases in the test suite.

The examples in the test suite are very difficult to understand if you expect it to be a simple chain!

On the one hand, I was very proud that I was able to work out the barely-documented behaviour of Windows SEH, and it was really thorough. In the initial implementation, all the complexity was covered. It wasn't the bugfix-driven-development which dmd usually operates under <g>.

But on the other hand, once you can see all of the complexity, exception chaining becomes much less convincing as a concept. Sure, the full exception tree is available in the final exception which you catch. But, is it of any use? I doubt it very much.
It's pretty clearly a nett loss to the language, it increases complexity with negligible benefit. Fortunately in this case, the cost isn't really high.

-Don.