On Friday, 24 August 2018 at 16:00:10 UTC, bachmeier wrote:
> 
>
> You simply can't share a D program with anyone else. It's an endless cycle of compiler upgrades and figuring out how to fix code that stops compiling. It doesn't work for those of us that are busy. Why there is not a stable branch with releases once a year is quite puzzling. (And no, "just use the old compiler" is not an answer.)

...hmm...I can't recall anyone ever suggesting to have a stable branch. It's a good idea.

That being said, I see forward progress on reducing breakage. The CI infrastructure has improved a lot and there are a number of dub projects that also get checked.

On Friday, 24 August 2018 at 03:53:38 UTC, David Nadlinger wrote:
> […]
> All this is not to say that nothrow constructors aren't a good idea, though.

This was meant to say nothrow DEstructors, as hopefully obvious from context. —David

On Fri, Aug 24, 2018 at 04:58:12PM +0000, jmh530 via Digitalmars-d wrote:
> On Friday, 24 August 2018 at 16:00:10 UTC, bachmeier wrote:
> > 
> > You simply can't share a D program with anyone else. It's an endless cycle of compiler upgrades and figuring out how to fix code that stops compiling.

I got bitten by this just yesterday.  Update dmd git master, update vibe.d git master, now my vibe.d project doesn't compile anymore due to some silly string.d error somewhere in one of vibe.d's dependencies. :-/

In the past this appeared to be a problem with out-of-date build targets, that was fixed by rebuilding everything from scratch.  But this time appears to be something else...


> > It doesn't work for those of us that are busy. Why there is not a stable branch with releases once a year is quite puzzling. (And no, "just use the old compiler" is not an answer.)
> 
> ...hmm...I can't recall anyone ever suggesting to have a stable branch. It's a good idea.
> 
> That being said, I see forward progress on reducing breakage. The CI infrastructure has improved a lot and there are a number of dub projects that also get checked.

This is probably completely unrealistic, but I've been thinking about the possibility of adding *all* D codebases to the CI infrastructure, including personal projects and what-not.  Set it up such that any breakages send a notification to the author(s) in advance of a PR being checked in, so that they have time to respond.  I'm not sure how this would work in practice since you have to deal with dead / unmaintained projects and/or slow/unresponsive authors, and some PRs you might want to push through regardless of breakage.  But it would be nice to know exactly how much code we're breaking out there.

Part of this is my suspicion that certain big, scary breaking changes actually may not have that big of an impact as we imagine, and could be worthwhile in the long run to get rid of wrinkles in the language and end up with a better, cleaner design that will last longer into the future.

But I'm probably just dreaming.


T

-- 
VI = Visual Irritation

On 8/24/18 10:02 AM, David Nadlinger wrote:
> On Friday, 24 August 2018 at 03:53:38 UTC, David Nadlinger wrote:
>> […]
>> All this is not to say that nothrow constructors aren't a good idea, though.
> 
> This was meant to say nothrow DEstructors, as hopefully obvious from context. —David

I was about to throw down some constructive criticism, but you caught it early ;)

On Friday, 24 August 2018 at 17:12:53 UTC, H. S. Teoh wrote:
> [snip]
>
> This is probably completely unrealistic, but I've been thinking about the possibility of adding *all* D codebases to the CI infrastructure, including personal projects and what-not.  Set it up such that any breakages send a notification to the author(s) in advance of a PR being checked in, so that they have time to respond.  I'm not sure how this would work in practice since you have to deal with dead / unmaintained projects and/or slow/unresponsive authors, and some PRs you might want to push through regardless of breakage.  But it would be nice to know exactly how much code we're breaking out there.

A worthy goal. If you could get some download statistics from dub (i.e. like total downloads past month), then you could probably create a few buckets and rules so you could make sure that there aren't breakages in the most downloaded projects while not worrying about dead projects that aren't being downloaded anyway.

On 8/23/2018 6:57 PM, Shachar Shemesh wrote:
> At this point I can either use the work-around I already have and (try to, obviously unsuccessfully) forget about it, file a bug report that will be (justifiably) ignored because no-one else can reproduce it, or spend an unknown amount of time (two days would probably be low-balling at this point) in trying to get this to reproduce on a watered down version of the code.
> 
> Which would you pick?

You should file a bug report, even with no example. It'll still be a clue, sometimes I can find problems without an example.

But still, assuming it is a compiler bug is a dodgy practice. I've drilled down on a lot of bug reports that the submitter was absolutely sure was a compiler bug, that turned out to be invalid.

On 8/24/2018 6:04 AM, Chris wrote:
> For about a year I've had the feeling that D is moving too fast and going nowhere at the same time. D has to slow down and get stable. D is past the experimental stage. Too many people use it for real world programming and programmers value and _need_ both stability and consistency.

Every programmer who says this also demands new (and breaking) features.

On Friday, 24 August 2018 at 19:26:40 UTC, Walter Bright wrote:
> On 8/24/2018 6:04 AM, Chris wrote:
>> For about a year I've had the feeling that D is moving too fast and going nowhere at the same time. D has to slow down and get stable. D is past the experimental stage. Too many people use it for real world programming and programmers value and _need_ both stability and consistency.
>
> Every programmer who says this also demands new (and breaking) features.

There's also who demands less (and may be breaking) features.

On Friday, 24 August 2018 at 19:26:40 UTC, Walter Bright wrote:
> On 8/24/2018 6:04 AM, Chris wrote:
>> For about a year I've had the feeling that D is moving too fast and going nowhere at the same time. D has to slow down and get stable. D is past the experimental stage. Too many people use it for real world programming and programmers value and _need_ both stability and consistency.
>
> Every programmer who says this also demands new (and breaking) features.

Some problems require new features like how taking the address of a member function without an object returns a function pointer, but requires a delegate where C++ has member function pointers, D just has broken unusable code. Or old features that were implemented poorly (C++ mangling for example).

On Thursday, 23 August 2018 at 11:02:31 UTC, Mike Franklin wrote:
> On Thursday, 23 August 2018 at 10:41:03 UTC, Jonathan M Davis wrote:
>
>> Languages pretty much always get more complicated over time, and unless we're willing to get rid of more stuff, it's guaranteed to just become more complicated over time rather than less.
>
> "A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away." -- Antoine de Saint-Exupery
>
> I think that's actually a mistranslation from what he actually said, but it's still quite good.

Liberties were taken there, but it's probably more applicable to this situation than a lot of the times C/Unix beards try to play it as though their tech of choice is beyond culpability.

For context, he's talking about the process of aeronautical engineering and the thrust of this statement is really commentary on effort and elegance.

A little before that, he talks about the grand irony that so much thoughtful effort and design goes into refining things so they're as simple as possible.  But "simple" is relative to the thing and the task (my understanding is that "simple" kind of conflates "reliable" here, too).  So this is where he rightly acknowledges that the process of refinement isn't a waste for what it removes even though it's often much greater than the effort to create something in the first place.

It's wrapped in a broader understanding that you have to have something that works at all before you can streamline it.

-Wyatt