On Thursday, 20 February 2020 at 10:36:35 UTC, Walter Bright wrote:
> On 2/20/2020 2:08 AM, Max Samukha wrote:
>> We encountered a case recently where we wanted to inline one. It was trivial to work around, though.
>
> I'm interested in evaluating common cases that don't inline but should.

Trivial functions that use a 'switch' to check membership in a small set of constants are still quite common I think, such as:

bool isReserved(char c) {
        switch (c) {
            case ':', '/', '?'...:
                return true;
            default:
                return false;
        }
}

On 2/20/2020 3:17 AM, NaN wrote:
> Would moving the inliner to the back end still slow down the compile times even when inlining is turned off?

If it was done right, probably not.

On Thursday, 20 February 2020 at 03:35:13 UTC, jxel wrote:
> [..]
> Just how the official DMD isn't built with LDC, why there
> isn't a 64 bit version of DMD on Windows [..]

Technically not true anymore!

https://github.com/dlang/installer/pull/425
https://github.com/dlang/installer/pull/417

See also:
https://github.com/dlang/installer/pulls?q=is%3Apr+is%3Aclosed

;)

On Thursday, 20 February 2020 at 06:08:03 UTC, Seb wrote:
>
> "Funnily" we changed the defaults for dub (one can't build anything with optlink, no vibe.d, no phobos etc. anyhow) more than a year ago and people are fine with dub using LLD (like LDC) and thus being able to have more than 32k symbols in their entire program, getting a 64-bit binary by default and not being linked with an ancient, full of well-known and decade-old bugs custom-brew Digitalmars libc.

Hello,

Reading the discussion, it seems something undervalued is the morale of contributors.

Getting and _keeping_ contributors is of paramount importance to open-source software. Some say that metric dwarf the importance of _having users_, and is the only real health metrics of a project.

Please (D leadership) consider keeping contributors happy, even if that means dropping a backend or OPTLINK or both. Projects that nly person understand can be "unbabyfied" with documentation/Wiki/years of contribution, but not having the problem in the first place is much easier.

On Thursday, 20 February 2020 at 13:11:21 UTC, Guillaume Piolat wrote:
> On Thursday, 20 February 2020 at 06:08:03 UTC, Seb wrote:
>>
>
> Please (D leadership) consider keeping contributors happy, even if that means dropping a backend or OPTLINK or both. Projects that nly person understand can be "unbabyfied" with documentation/Wiki/years of contribution, but not having the problem in the first place is much easier.

If what Seb says is true, that almost all current contributors would like to switch and it's not even being considered, it doesnt bode well.

On Thursday, 20 February 2020 at 13:11:21 UTC, Guillaume Piolat wrote:
> 
>
> Please (D leadership) consider keeping contributors happy, even if that means dropping a backend or OPTLINK or both. Projects that nly person understand can be "unbabyfied" with documentation/Wiki/years of contribution, but not having the problem in the first place is much easier.

I think you need to be a bit more concrete in explaining how dropping a backend would keep contributors happy. In the time I've been following D, the people I've seen complain about multiple backends are rarely participants very long at all. To the point, where I would almost suggest putting something up on the wiki about the motivation here and then just always linking to that when people bring it up every few months. By contrast, the people I've observed who were more active participants and then stop contributing usually complain about other things, like their pull requests being ignored.

On Thursday, 20 February 2020 at 14:31:44 UTC, jmh530 wrote:
>
> I think you need to be a bit more concrete in explaining how dropping a backend would keep contributors happy.

Have you read Seb suggestions?

On Thursday, 20 February 2020 at 14:31:44 UTC, jmh530 wrote:
> By contrast, the people I've observed who were more active participants and then stop contributing usually complain about other things, like their pull requests being ignored.

Now imagine if Linux spent all his time implementing Linux drivers instead of spending all its time reviewing. He would probably say "there is no time for review".

On Thursday, 20 February 2020 at 05:54:13 UTC, Mike Parker wrote:
> On Thursday, 20 February 2020 at 03:35:13 UTC, jxel wrote:
>
>> one expects these things to change. What seems like common sense means nothing to someone stubborn and blinded by pride.
>
> There are historical reasons why Optlink is still around and they have nothing to do with stubbornness or pride. Please make your points without going ad hominem.

Being around for backwards compatibility and STILL BEING USED IN RELEASES are two very different things. Historical is the only thing that should describe Optlink. With all the breaking changes that are already happening, one can't really argue keeping it to maintain backwards compatibility either.

Anyways it seems we are one step closer to that, if the PR doesn't get reversed before release.

On Thursday, 20 February 2020 at 14:37:36 UTC, Guillaume Piolat wrote:
> On Thursday, 20 February 2020 at 14:31:44 UTC, jmh530 wrote:
>>
>> I think you need to be a bit more concrete in explaining how dropping a backend would keep contributors happy.
>
> Have you read Seb suggestions?

Had to go back to re-read it. It's more of a list of issues with supporting multiple compilers than a list of suggestions, but it does address my point about keeping contributors happy. It sounds like a tricky management problem, to be honest. However, I think there is an important trade-off to consider between the value of keeping DMD and the cost of maintaining support for it. For instance, I don't know how much more work it is to maintain CIs for three compilers rather than two. It doesn't sound like much more work, but I really have no idea. Similarly, I would expect that the other backends would need to support new features, even if DMD is put out to pasture. That cost doesn't go away. Regardless, I would hope that Walter considers it is possible to reduce the cost for some of those issues.