On Thursday, 8 October 2020 at 12:40:55 UTC, Jacob Carlborg wrote:
> On Thursday, 8 October 2020 at 10:37:22 UTC, FeepingCreature wrote:
>> But that's not my biggest objection. This is: the purpose of a language is the code that people write in it. Are we acknowledging that most code in D has already been written? Are we giving up on growth? Are we saying "the level of popularity that D has currently reached is probably at or beyond the peak of usage"? Because if not, if we think that most code written in D is still to come, then we are harming people's future experience with D at the expense of not harming legacy code. I think this is a self-fulfilling prophecy that will kill the language.
>
> That's what Scott Meyers said at DConf: most D code is not written yet. Don't make me come back again. Then he did come back again.
>
> --
> /Jacob Carlborg

I don't really agree with this sort of mentality. If you keep breaking code then the most D code won't ever be written. Broken code that doesn't end up being fixed will stay broken. This stuns growth, especially for larger projects. Constantly fixing breaking changes is fine for smaller projects, but its a disaster for large projects.

On Friday, 9 October 2020 at 15:16:32 UTC, Fred wrote:
> I don't really agree with this sort of mentality. If you keep breaking code then the most D code won't ever be written. Broken code that doesn't end up being fixed will stay broken. This stuns growth, especially for larger projects. Constantly fixing breaking changes is fine for smaller projects, but its a disaster for large projects.

On CPPCON they discussed what it would take to move from implicit constructors by default to explicit constructors by default.

They could do it like this:

year 1: deprecate unqualified constructors and issue warnings, so you have to write either "explicit" or "implicit" before all constructors.

year 20: make unqualified destructors "explicit"

LOL

I think there is a difference between a language with millions of users and other languages though. Major versions is a good solution for most languages, especially if all changes are caught at compile-time.

On Friday, 9 October 2020 at 15:27:26 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 9 October 2020 at 15:16:32 UTC, Fred wrote:
>> I don't really agree with this sort of mentality. If you keep breaking code then the most D code won't ever be written. Broken code that doesn't end up being fixed will stay broken. This stuns growth, especially for larger projects. Constantly fixing breaking changes is fine for smaller projects, but its a disaster for large projects.
>
> On CPPCON they discussed what it would take to move from implicit constructors by default to explicit constructors by default.
>
> They could do it like this:

Uh, that was wrong, more like this:

year 1: deprecate unqualified constructors and issue warnings, so you have to write either "explicit" or "implicit" before all constructors.

year 10: make unqualified constructors illegal

year 20: make unqualified constructors "explicit"

The idea is we don't want to break documented behavior that people used in good faith, unless we *have* to. If people are exploiting a bug in the compiler, I'm not terribly sympathetic to that, and fixing that bug is not a problem. We don't *have* to remove the old operator new and delete overloads. We can "un-document" it, i.e. move its documentation to a separate section of the documentation, and encourage people to leave it behind.

I don't see how this takes anything away from D.

On 10/8/2020 3:37 AM, FeepingCreature wrote:
> I think this is to some extent an inherent problem with the D *forum.* In Github and other forum software, you can give upvotes, thumbs-up or likes to posts as a way of signalling agreement. The D forum, due to its NNTP heritage, does not have this capability.

The D community has a large diversity of members that run the gamut of experience levels. Should a person who just compiled his first D program yesterday have a vote counting as much as, say, yours?

Democracy is fine for politics, not for engineering. Would you feel safer on an airplane designed by the general public voting on how thick to make the wing spar, or by experienced aerospace engineers?

I look for compelling, well-founded opinions by people who are long-time contributors with a track record of demonstrated expertise. People who have a stake in D, who care about it and will have to live with the results.

(That said, I still welcome perspectives by people new to D, as they may bring expertise to the table that none of us have. Sometimes the best ideas come from outsiders.)

It goes without saying that reviews consisting of nothing more than +1 are not compelling. At least give some sort of rationale.

On 10/8/2020 3:37 AM, FeepingCreature wrote:
> But that's not my biggest objection. This is: the purpose of a language is the code that people write in it. Are we acknowledging that most code in D has already been written? Are we giving up on growth? Are we saying "the level of popularity that D has currently reached is probably at or beyond the peak of usage"? Because if not, if we think that most code written in D is still to come, then we are harming people's future experience with D at the expense of not harming legacy code. I think this is a self-fulfilling prophecy that will kill the language.

I honestly don't know where this is coming from. There are a number of proposals in the DIP queue. Stefan is working on type functions. I'm working on an alternative method to speed up template metaprogramming. Steven is outlining a Phobos std2 design. I'm working on an ownership/borrowing addition.

As for the named parameter DIP, it was approved. My string formatting DIP was rejected, even though I strongly feel it is the right move for D, because nobody else seemed to want it. There is a long list of -preview switches implemented.

> When I can switch from 2.090.1 to 2.094.0 and often only get warnings, I'm more upset than happy

I interpret that as we're doing a good job not breaking peoples' code :-/

On 10/8/2020 6:30 AM, kinke wrote:
> What makes matters worse in this regard is the Buildkite CI integration. E.g., https://github.com/dlang/dmd/pull/11387 is a bugfix but blocked as it breaks 5 3rd-party projects.

Each 3rd party library in github needs to have a maintainer (preferably the developer of it) who agrees to keep it updated. If there is no maintainer and it breaks, remove support for it from buildkite.

buildkite needs to provide the email address of the maintainer in its build log.

I don't see any other practical way.

> I have more important stuff to do than to fix unrelated code to get a fix in.

Right on. We all do.

On 10/9/2020 3:58 AM, FeepingCreature wrote:
> This is the core point - we don't see our code as "in maintenance mode". We want to write new code, add new features - and nothing is more frustrating than spending days, paid for by the company, to reduce a bug and find out it was deliberately left unfixed, or that the D project left you to sink weeks of effort into a barely-maintained semi-legacy part of the language that you now have to refactor your way out of, cough std.json cough.

std.json is still in Phobos, and still passes its unittests. I do not understand what the issue is with it - if you're using it, and it hasn't changed, why do you have to refactor out of it?