• Walter Bright (6/6) Jan 16 https://github.com/dlang/dmd/pull/15715
• M. M. (5/12) Jan 16 Indeed, the discussion led to several ideas and
• Paolo Invernizzi (6/13) Jan 16 Kudos to everyone involved, and especially a great thanks to
• Adam Wilson (4/11) Jan 16 This came out of nowhere but I am excited to see it! And I am
• Andrej Mitrovic (3/10) Jan 16 Is this going to go behind a feature flag or be part of the
• Walter Bright (3/4) Jan 16 Since it is does not affect any other features, there is no reason to pu...
• zjh (5/9) Jan 16 In fact, two switches can also be provided for continuous
• zjh (4/7) Jan 16 `Dip ` can be continuously enhanced and even revoked it during
• ryuukk_ (15/27) Jan 17 I agree with that
• RazvanN (7/36) Jan 17 Please be careful with that switch as it has a lot of bugs (and
• ryuukk_ (4/49) Jan 17 It's been working just fine for me, for years already, i don't do
• zjh (4/10) Jan 17 These details should be noted in the document.
• Timon Gehr (3/47) Jan 17 Well, Phobos relies on rvalues not binding to ref parameters in order to...
• zjh (6/13) Jan 17 Yes, why don't I participate in these debates because I can't
• Siarhei Siamashka (4/5) Jan 17 Why is this so? Do you find it difficult to build a patched DMD
• zjh (7/13) Jan 17 I am a beginner user, I just want to use it unboxing. I am too
• zjh (14/17) Jan 17 `Countless dips`, as long as contributors think there is a `good
• zjh (3/4) Jan 17 Transform the `'dip'` of `'d'` into a `'vim '`like' `plugin` that
• Meta (6/23) Jan 17 This is a good point. Rust has unstable features that are only
• Meta (4/9) Jan 17 Forgot the link:
• Walter Bright (10/15) Jan 17 If you can build the compiler, it's not hard to merge a fork into your l...
• Siarhei Siamashka (24/27) Jan 18 It doesn't work like this. The process of building DMD starts
• GrimMaple (7/36) Jan 18 Funny thing is, DMD is super easy to build on Windows. You just
• Walter Bright (4/8) Jan 19 The instructions are on a wiki - anyone can fix it.
• Siarhei Siamashka (10/12) Jan 18 It's not necessary to maintain binaries of each PR. We are
• aberba (3/20) Jan 18 Majority isn't always right. This might not end up well. Debate
• Steven Schveighoffer (9/16) Jan 16 Thanks for approving this! I think it will be a great addition to
• Don Allen (3/10) Jan 16 Graciously admitting when you are wrong is as much a part of
• claptrap (25/28) Jan 17 Its nice that you're able to put a positive spin on it but the
• Dibyendu Majumdar (5/13) Jan 17 You are wrong. This is not a democracy. Walter is the BDFL for D,
• claptrap (7/23) Jan 17 I never said anything at odds with that.
• Dibyendu Majumdar (5/8) Jan 17 Its people like you who are the problem.
• claptrap (21/30) Jan 17 Are we in Noth Korea? People who dare to criticise the Dear
• M.M. (4/10) Jan 17 I understand your desire to have Walter more explicitly detached
• claptrap (6/18) Jan 17 Yes but it was resurrected in response to the thread about 1036.
• claptrap (4/16) Jan 17 It's more that he should not have used the talk about 1036 to
• M.M. (24/41) Jan 17 I myself saw his comparison of DIP1027 to DIP1036, YAIDIP, and
• bachmeier (7/15) Jan 17 That was my interpretation too. I didn't read all of the posts,
• claptrap (7/15) Jan 17 I agree with most of what you've said.
• GrimMaple (31/33) Jan 17 I was trying to refrain from this forum, but oh boy.
• DrDread (5/15) Jan 18 see, there's your problem. it's not the contributors job, they do
• Mike Parker (7/13) Jan 18 Wrong. Spending your free time on a contribution does not
• DrDread (5/20) Jan 18 you are still missing the point. it's not about rejecting a
• Dibyendu Majumdar (9/13) Jan 18 This is an OpenSource project - everyone works on such projects
• Siarhei Siamashka (6/8) Jan 18 OpenSource does not imply non-commercial. In fact, many people
• Serg Gini (14/16) Jan 18 Open Source model is not working in huge products usually..
• claptrap (5/10) Jan 18 I have no obligation to be nice to my freinds.
• Dibyendu Majumdar (5/15) Jan 18 It only proves my point, because the only people not nice on
• H. S. Teoh (15/19) Jan 18 That's irrelevant. Some of the people who left recently were *very*
• Dibyendu Majumdar (14/24) Jan 18 Please would you elaborate on what you mean by how they were
• Don Allen (32/58) Jan 18 And even that is not guaranteed to work. The kinds of conflicts
• H. S. Teoh (39/54) Jan 18 I've already said this before elsewhere, but in short: an eager
• Walter Bright (21/21) Jan 20 Andrei left us years ago. Complaining about him is pointless.
• Adam Wilson (54/60) Jan 21 I think we need to specify what we mean when we say "low quality
• Dom DiSc (9/23) Jan 21 Oh please.
• matheus (8/17) Jan 21 I always thought that the code should be accompanying with a
• Richard (Rikki) Andrew Cattermole (4/16) Jan 21 Yes, that has been added to the PhobosV3 proposal by Adam.
• Meta (8/31) Jan 21 Yes, yes, and yes. At work we have a linter that IS integrated
• kdevel (33/36) Jan 21 What about code which is more art than craft?
• Richard (Rikki) Andrew Cattermole (18/18) Jan 21 If you need to disable dfmt for a block of code, disable it.
• Walter Bright (2/2) Jan 21 Many of my PRs have been nitpicked. I just fix them, it's easier than ar...
• Elias Batek (0xEAB) (6/8) Jan 21 I think, I said this one Discord a while ago, it’s usually so
• Mike Parker (54/58) Jan 18 I'm going to leave a few paragraphs here about this and then I'll
• H. S. Teoh (13/21) Jan 18 [...]
• Dibyendu Majumdar (9/13) Jan 18 I feel that with any project, there will never be the same set of
• H. S. Teoh (15/29) Jan 18 The way D is being run, it *should* have been a commercial organization
• aberba (21/36) Jan 18 Naa,man, I doubt you have any idea the background story of this
• Walter Bright (6/6) Jan 20 People leave for many reasons. Often their situation and interests chang...
• matheus (4/8) Jan 18 Jonathan Marler which by the way was trying to implement a String
• Adam D Ruppe (153/157) Jan 18 I unsubscribed from this forum, since I find it to make me angry
• Don Allen (7/14) Jan 21 You are excusing the inexcusable, blaming it on someone else.
• aberba (8/21) Jan 18 how do you know even those folks aren't contributors financially
• H. S. Teoh (15/37) Jan 18 I said specifically I was *not* talking about them. :-D
• zjh (8/9) Jan 18 D's `feedback` is too slow. They are fixated on `details` but not
• claptrap (11/29) Jan 18 LOL you aint proved nothing. You cant because you dont know who
• M.M. (21/44) Jan 18 Let's hold on. There is this general critique of how DLF manages
• cc (2/9) Jan 18 Looking forward to this, thanks to all involved.

Walter Bright <newshound2 digitalmars.com> writes:

https://github.com/dlang/dmd/pull/15715

I was unconvincing in my arguments, there was too much acrimony, and its
effects 
do not affect the rest of the language. The only credit I can take is my 
constant challenges to it caused it to evolve into a much better proposal.

Steven has graciously volunteered to work on the addition to the language spec, 
thank you!

M. M. <matus email.cz> writes:

On Tuesday, 16 January 2024 at 20:38:37 UTC, Walter Bright wrote:
 https://github.com/dlang/dmd/pull/15715

 I was unconvincing in my arguments, there was too much 
 acrimony, and its effects do not affect the rest of the 
 language. The only credit I can take is my constant challenges 
 to it caused it to evolve into a much better proposal.

 Steven has graciously volunteered to work on the addition to 
 the language spec, thank you!

Indeed, the discussion led to several ideas and 
shortcoming-discoveries, resulting in gradually improved 
proposals.

Well done everyone involved.

Paolo Invernizzi <paolo.invernizzi gmail.com> writes:

On Tuesday, 16 January 2024 at 20:38:37 UTC, Walter Bright wrote:
 https://github.com/dlang/dmd/pull/15715

 I was unconvincing in my arguments, there was too much 
 acrimony, and its effects do not affect the rest of the 
 language. The only credit I can take is my constant challenges 
 to it caused it to evolve into a much better proposal.

 Steven has graciously volunteered to work on the addition to 
 the language spec, thank you!

Kudos to everyone involved, and especially a great thanks to 
Walter (and ... arsd too!)
Happy to see the grow of mutual trusting between the great team 
of people D has!

/P, proud D (commercial) user since 2004!

Adam Wilson <flyboynw gmail.com> writes:

On Tuesday, 16 January 2024 at 20:38:37 UTC, Walter Bright wrote:
 https://github.com/dlang/dmd/pull/15715

 I was unconvincing in my arguments, there was too much 
 acrimony, and its effects do not affect the rest of the 
 language. The only credit I can take is my constant challenges 
 to it caused it to evolve into a much better proposal.

 Steven has graciously volunteered to work on the addition to 
 the language spec, thank you!

This came out of nowhere but I am excited to see it! And I am 
looking forward to discussing this whole process when we meet-up 
next. I can see many lessons we can learn from this.

Andrej Mitrovic <andrej.mitrovich gmail.com> writes:

On Tuesday, 16 January 2024 at 20:38:37 UTC, Walter Bright wrote:
 https://github.com/dlang/dmd/pull/15715

 I was unconvincing in my arguments, there was too much 
 acrimony, and its effects do not affect the rest of the 
 language. The only credit I can take is my constant challenges 
 to it caused it to evolve into a much better proposal.

 Steven has graciously volunteered to work on the addition to 
 the language spec, thank you!

Is this going to go behind a feature flag or be part of the 
upcoming "editions"?

Walter Bright <newshound2 digitalmars.com> writes:

On 1/16/2024 5:15 PM, Andrej Mitrovic wrote:
 Is this going to go behind a feature flag or be part of the upcoming
"editions"?

Since it is does not affect any other features, there is no reason to put it 
behind a feature flag.

zjh <fqbqrr 163.com> writes:

On Tuesday, 16 January 2024 at 20:38:37 UTC, Walter Bright wrote:
 https://github.com/dlang/dmd/pull/15715

 I was unconvincing in my arguments, there was too much 
 acrimony, and its effects do not affect the rest of the 
 language.



In fact, two switches can also be provided for continuous 
feedback during use.
We should also establish an `experimental mechanism` that allows 
for the revocation of the switch if it causes significant harm!

zjh <fqbqrr 163.com> writes:

On Wednesday, 17 January 2024 at 02:16:01 UTC, zjh wrote:

 We should also establish an `experimental mechanism` that 
 allows for the revocation of the switch if it causes 
 significant harm!


`Dip ` can be continuously enhanced and even revoked it during 
use!

Instead of endless debates, it's too waste of time!

ryuukk_ <ryuukk.dev gmail.com> writes:

On Wednesday, 17 January 2024 at 02:16:01 UTC, zjh wrote:
 On Tuesday, 16 January 2024 at 20:38:37 UTC, Walter Bright 
 wrote:
 https://github.com/dlang/dmd/pull/15715

 I was unconvincing in my arguments, there was too much 
 acrimony, and its effects do not affect the rest of the 
 language.



 In fact, two switches can also be provided for continuous 
 feedback during use.
 We should also establish an `experimental mechanism` that 
 allows for the revocation of the switch if it causes 
 significant harm!

I agree with that

It should have been like other features, both under -preview 
switch, then a period of several months for testing, then a 
debate in forums about wich is better

Do this with tuple, pattern matching, and tagged union, so people 
can test, give feedback, propose improvements without commitment 
for integration


I already use 2 preview switches in my project:

-preview=rvaluerefparam
-preview=bitfields


I love rvaluerefparam, it should go core, but bitfields is imo 
bad, i'd prefer to be able to get bit specific integer type 
instead..

I personally have no need for string interpolation

RazvanN <razvan.nitu1305 gmail.com> writes:

On Wednesday, 17 January 2024 at 14:19:37 UTC, ryuukk_ wrote:
 On Wednesday, 17 January 2024 at 02:16:01 UTC, zjh wrote:
 On Tuesday, 16 January 2024 at 20:38:37 UTC, Walter Bright 
 wrote:
 https://github.com/dlang/dmd/pull/15715

 I was unconvincing in my arguments, there was too much 
 acrimony, and its effects do not affect the rest of the 
 language.



 In fact, two switches can also be provided for continuous 
 feedback during use.
 We should also establish an `experimental mechanism` that 
 allows for the revocation of the switch if it causes 
 significant harm!

 I agree with that

 It should have been like other features, both under -preview 
 switch, then a period of several months for testing, then a 
 debate in forums about wich is better

 Do this with tuple, pattern matching, and tagged union, so 
 people can test, give feedback, propose improvements without 
 commitment for integration


 I already use 2 preview switches in my project:

 -preview=rvaluerefparam
 -preview=bitfields


 I love rvaluerefparam, it should go core, but bitfields is imo 
 bad, i'd prefer to be able to get bit specific integer type 
 instead..

Please be careful with that switch as it has a lot of bugs (and 
as far as I remember it's not completely implemented). I have 
tried turning it on by default in the compiler and was not able 
to compile phobos (however, I do not remember what the problems 
were).

RazvanN

ryuukk_ <ryuukk.dev gmail.com> writes:

On Wednesday, 17 January 2024 at 14:26:29 UTC, RazvanN wrote:
 On Wednesday, 17 January 2024 at 14:19:37 UTC, ryuukk_ wrote:
 On Wednesday, 17 January 2024 at 02:16:01 UTC, zjh wrote:
 On Tuesday, 16 January 2024 at 20:38:37 UTC, Walter Bright 
 wrote:
 https://github.com/dlang/dmd/pull/15715

 I was unconvincing in my arguments, there was too much 
 acrimony, and its effects do not affect the rest of the 
 language.



 In fact, two switches can also be provided for continuous 
 feedback during use.
 We should also establish an `experimental mechanism` that 
 allows for the revocation of the switch if it causes 
 significant harm!

 I agree with that

 It should have been like other features, both under -preview 
 switch, then a period of several months for testing, then a 
 debate in forums about wich is better

 Do this with tuple, pattern matching, and tagged union, so 
 people can test, give feedback, propose improvements without 
 commitment for integration


 I already use 2 preview switches in my project:

 -preview=rvaluerefparam
 -preview=bitfields


 I love rvaluerefparam, it should go core, but bitfields is imo 
 bad, i'd prefer to be able to get bit specific integer type 
 instead..

 Please be careful with that switch as it has a lot of bugs (and 
 as far as I remember it's not completely implemented). I have 
 tried turning it on by default in the compiler and was not able 
 to compile phobos (however, I do not remember what the problems 
 were).

 RazvanN

It's been working just fine for me, for years already, i don't do 
RAII or complex stuff with constructors tho, so that's maybe why

Are the issues referenced somewhere?

zjh <fqbqrr 163.com> writes:

On Wednesday, 17 January 2024 at 14:26:29 UTC, RazvanN wrote:

 Please be careful with that switch as it has a lot of bugs (and 
 as far as I remember it's not completely implemented). I have 
 tried turning it on by default in the compiler and was not able 
 to compile phobos (however, I do not remember what the problems 
 were).

 RazvanN


These details should be noted in the document.
The `more information` in the document, the more users can obtain 
the `most real situation`.

Timon Gehr <timon.gehr gmx.ch> writes:

On 1/17/24 15:26, RazvanN wrote:
 On Wednesday, 17 January 2024 at 14:19:37 UTC, ryuukk_ wrote:
 On Wednesday, 17 January 2024 at 02:16:01 UTC, zjh wrote:
 On Tuesday, 16 January 2024 at 20:38:37 UTC, Walter Bright wrote:
 https://github.com/dlang/dmd/pull/15715

 I was unconvincing in my arguments, there was too much acrimony, and 
 its effects do not affect the rest of the language.



 In fact, two switches can also be provided for continuous feedback 
 during use.
 We should also establish an `experimental mechanism` that allows for 
 the revocation of the switch if it causes significant harm!

 I agree with that

 It should have been like other features, both under -preview switch, 
 then a period of several months for testing, then a debate in forums 
 about wich is better

 Do this with tuple, pattern matching, and tagged union, so people can 
 test, give feedback, propose improvements without commitment for 
 integration


 I already use 2 preview switches in my project:

 -preview=rvaluerefparam
 -preview=bitfields


 I love rvaluerefparam, it should go core, but bitfields is imo bad, 
 i'd prefer to be able to get bit specific integer type instead..

 
 Please be careful with that switch as it has a lot of bugs (and as far 
 as I remember it's not completely implemented). I have tried turning it 
 on by default in the compiler and was not able to compile phobos 
 (however, I do not remember what the problems were).
 
 RazvanN
 
 

Well, Phobos relies on rvalues not binding to ref parameters in order to 
check via `__traits(compiles, ...)` whether something is an lvalue.

zjh <fqbqrr 163.com> writes:

On Wednesday, 17 January 2024 at 14:19:37 UTC, ryuukk_ wrote:

 I already use 2 preview switches in my project:

 -preview=rvaluerefparam
 -preview=bitfields


 I love rvaluerefparam, it should go core, but bitfields is imo 
 bad, i'd prefer to be able to get bit specific integer type 
 instead..

 I personally have no need for string interpolation


Yes, why don't I participate in these debates because I can't 
even `try them out`. How do I know the `pros and cons`?
Only after `practical testing` can a more specific understanding 
be obtained. Otherwise, it is just `nonsense`.
And the `endless debate` is a waste of time!

Siarhei Siamashka <siarhei.siamashka gmail.com> writes:

On Wednesday, 17 January 2024 at 15:07:08 UTC, zjh wrote:
 I can't even `try them out`.

Why is this so? Do you find it difficult to build a patched DMD 
yourself? Would it help to have pre-built binary compiler 
releases for every DIP available for download somewhere?

zjh <fqbqrr 163.com> writes:

On Wednesday, 17 January 2024 at 15:12:58 UTC, Siarhei Siamashka 
wrote:
 On Wednesday, 17 January 2024 at 15:07:08 UTC, zjh wrote:
 I can't even `try them out`.

 Why is this so? Do you find it difficult to build a patched DMD 
 yourself?

I am a beginner user, I just want to use it unboxing. I am too 
lazy.

 Would it help to have pre-built binary compiler releases for 
 every DIP available for download somewhere?


I think it's more convenient to integrate it into the 
`'experimental switch'`, after all, there maybe too many 
experiments `dip` switch.

zjh <fqbqrr 163.com> writes:

On Wednesday, 17 January 2024 at 15:17:47 UTC, zjh wrote:

 I think it's more convenient to integrate it into the 
 `'experimental switch'`, after all, there maybe too many 
 experiments `dip` switch.


`Countless dips`, as long as contributors think there is a `good 
idea`, they can try it out, and then, if everyone thinks it's 
good, they can join.
If there are still issues, they can be continuously corrected 
during use, while also improving the details of the dip.
If there is a major problem and the 'dip' is not recommended, 
cancel it!
Very similar to the plugin style development of vim!
These switches are implemented by contributors, which can fully 
mobilize their enthusiasm!

`Dip1027/Dip1036` can all be added, experiment for `1 year or 
half a year`, and then see which is better! Instead of endless 
debates.

zjh <fqbqrr 163.com> writes:

On Wednesday, 17 January 2024 at 15:30:27 UTC, zjh wrote:

 Very similar to the plugin style development of vim!

Transform the `'dip'` of `'d'` into a `'vim '`like' `plugin` that 
users can freely `assemble` and update at any time.

Meta <jared771 gmail.com> writes:

On Wednesday, 17 January 2024 at 15:30:27 UTC, zjh wrote:
 On Wednesday, 17 January 2024 at 15:17:47 UTC, zjh wrote:

 I think it's more convenient to integrate it into the 
 `'experimental switch'`, after all, there maybe too many 
 experiments `dip` switch.


 `Countless dips`, as long as contributors think there is a 
 `good idea`, they can try it out, and then, if everyone thinks 
 it's good, they can join.
 If there are still issues, they can be continuously corrected 
 during use, while also improving the details of the dip.
 If there is a major problem and the 'dip' is not recommended, 
 cancel it!
 Very similar to the plugin style development of vim!
 These switches are implemented by contributors, which can fully 
 mobilize their enthusiasm!

 `Dip1027/Dip1036` can all be added, experiment for `1 year or 
 half a year`, and then see which is better! Instead of endless 
 debates.

This is a good point. Rust has unstable features that are only 
available on their nightly builds. Some of them are also gated 
behind a feature flag. The end result is that the community has 
plenty of time to test out new features and hash out any dark 
corners.

Meta <jared771 gmail.com> writes:

On Wednesday, 17 January 2024 at 19:29:28 UTC, Meta wrote:
 This is a good point. Rust has unstable features that are only 
 available on their nightly builds. Some of them are also gated 
 behind a feature flag. The end result is that the community has 
 plenty of time to test out new features and hash out any dark 
 corners.

Forgot the link:
https://doc.rust-lang.org/rustdoc/unstable-features.html
https://doc.rust-lang.org/unstable-book/index.html

Walter Bright <newshound2 digitalmars.com> writes:

On 1/17/2024 7:07 AM, zjh wrote:
 Yes, why don't I participate in these debates because I can't even `try them 
 out`. How do I know the `pros and cons`?
 Only after `practical testing` can a more specific understanding be obtained. 
 Otherwise, it is just `nonsense`.
 And the `endless debate` is a waste of time!

If you can build the compiler, it's not hard to merge a fork into your local 
copy and then build it.

I had trouble with that because every search query gave me the wrong git
command 
to do this. I wound up asking some team members, and got the right command.

The forking system is the way to do this. It isn't very practical to try and 
maintain binaries of each PR.

DMD is pretty friendly to build from scratch. On my machine:

time make debug

takes 26 seconds to build on an ancient Linux box.

Siarhei Siamashka <siarhei.siamashka gmail.com> writes:

On Wednesday, 17 January 2024 at 20:42:24 UTC, Walter Bright 
wrote:
 DMD is pretty friendly to build from scratch. On my machine:

 time make debug

 takes 26 seconds to build on an ancient Linux box.

It doesn't work like this. The process of building DMD starts 
from going to https://github.com/dlang/dmd and then reading (or 
at least skimming through) a number of web pages and clicking 
through them to navigate to the right place with the appropriate 
build instructions:
* https://github.com/dlang/dmd/blob/master/CONTRIBUTING.md
* https://wiki.dlang.org/DMD
* 
https://wiki.dlang.org/Starting_as_a_Contributor#Building_from_source
* https://wiki.dlang.org/Building_under_Posix

This kinda violates the 
https://en.wikipedia.org/wiki/Three-click_rule, which isn't a 
gospel, but still has some merit. All of this together is surely 
doable, but takes way longer than 26 seconds and the CPU speed 
isn't the bottleneck.

And I'm even not talking about building D compilers on unpopular 
marginal operating systems, such as Windows, which barely have 
any support at all:
* 
https://forum.dlang.org/thread/nrctztchyvfluyiohwvo forum.dlang.org
* 
https://forum.dlang.org/thread/yrczwiwfofqkqcvnraqc forum.dlang.org

GrimMaple <grimmaple95 gmail.com> writes:

On Thursday, 18 January 2024 at 09:29:03 UTC, Siarhei Siamashka 
wrote:
 On Wednesday, 17 January 2024 at 20:42:24 UTC, Walter Bright 
 wrote:
 DMD is pretty friendly to build from scratch. On my machine:

 time make debug

 takes 26 seconds to build on an ancient Linux box.

 It doesn't work like this. The process of building DMD starts 
 from going to https://github.com/dlang/dmd and then reading (or 
 at least skimming through) a number of web pages and clicking 
 through them to navigate to the right place with the 
 appropriate build instructions:
 * https://github.com/dlang/dmd/blob/master/CONTRIBUTING.md
 * https://wiki.dlang.org/DMD
 * 
 https://wiki.dlang.org/Starting_as_a_Contributor#Building_from_source
 * https://wiki.dlang.org/Building_under_Posix

 This kinda violates the 
 https://en.wikipedia.org/wiki/Three-click_rule, which isn't a 
 gospel, but still has some merit. All of this together is 
 surely doable, but takes way longer than 26 seconds and the CPU 
 speed isn't the bottleneck.

 And I'm even not talking about building D compilers on 
 unpopular marginal operating systems, such as Windows, which 
 barely have any support at all:
 * 
 https://forum.dlang.org/thread/nrctztchyvfluyiohwvo forum.dlang.org
 * 
 https://forum.dlang.org/thread/yrczwiwfofqkqcvnraqc forum.dlang.org

Funny thing is, DMD is super easy to build on Windows. You just 
have to somehow figure out to `rdmd build.d` in the `compiler` 
directory and then it's all good. Phobos/Druntime on the other 
hand simply cannot be built on windows, because instructions tell 
you to use `make` that "comes with dmd`, and it just doesn't :)

Walter Bright <newshound2 digitalmars.com> writes:

On 1/18/2024 1:49 AM, GrimMaple wrote:
 Funny thing is, DMD is super easy to build on Windows. You just have to
somehow 
 figure out to `rdmd build.d` in the `compiler` directory and then it's all
good. 
 Phobos/Druntime on the other hand simply cannot be built on windows, because 
 instructions tell you to use `make` that "comes with dmd`, and it just doesn't
:)

The instructions are on a wiki - anyone can fix it.

https://wiki.dlang.org/Building_under_Windows

https://issues.dlang.org/show_bug.cgi?id=24347

Siarhei Siamashka <siarhei.siamashka gmail.com> writes:

On Wednesday, 17 January 2024 at 20:42:24 UTC, Walter Bright 
wrote:
 The forking system is the way to do this. It isn't very 
 practical to try and maintain binaries of each PR.

It's not necessary to maintain binaries of each PR. We are 
talking about potentially having pre-built compiler binaries for 
DIP1036e or for any other proposed *controversial* language 
features, which instigate a lot of debates. The point was made 
about the existence of a certain fraction of users, who have no 
skills or patience to build the patched compiler themselves. 
These people feel left out. Well, in a way that's their fault and 
nobody has any obligation to help them.

aberba <karabutaworld gmail.com> writes:

On Wednesday, 17 January 2024 at 15:07:08 UTC, zjh wrote:
 On Wednesday, 17 January 2024 at 14:19:37 UTC, ryuukk_ wrote:

 I already use 2 preview switches in my project:

 -preview=rvaluerefparam
 -preview=bitfields


 I love rvaluerefparam, it should go core, but bitfields is imo 
 bad, i'd prefer to be able to get bit specific integer type 
 instead..

 I personally have no need for string interpolation


 Yes, why don't I participate in these debates because I can't 
 even `try them out`. How do I know the `pros and cons`?
 Only after `practical testing` can a more specific 
 understanding be obtained. Otherwise, it is just `nonsense`.
 And the `endless debate` is a waste of time!

Majority isn't always right. This might not end up well. Debate 
is good. Just have to be healthy.

Steven Schveighoffer <schveiguy gmail.com> writes:

On Tuesday, 16 January 2024 at 20:38:37 UTC, Walter Bright wrote:
 https://github.com/dlang/dmd/pull/15715

 I was unconvincing in my arguments, there was too much 
 acrimony, and its effects do not affect the rest of the 
 language. The only credit I can take is my constant challenges 
 to it caused it to evolve into a much better proposal.

 Steven has graciously volunteered to work on the addition to 
 the language spec, thank you!

Thanks for approving this! I think it will be a great addition to 
the language.

I will start working on the spec this week, and would volunteer 
also to implement any specific updates (assuming I have the 
skills) that need to be done for merging.

I know at least one that we could do that I mentioned a while 
back...

-Steve

Don Allen <donaldcallen gmail.com> writes:

On Tuesday, 16 January 2024 at 20:38:37 UTC, Walter Bright wrote:
 https://github.com/dlang/dmd/pull/15715

 I was unconvincing in my arguments, there was too much 
 acrimony, and its effects do not affect the rest of the 
 language. The only credit I can take is my constant challenges 
 to it caused it to evolve into a much better proposal.

 Steven has graciously volunteered to work on the addition to 
 the language spec, thank you!

Graciously admitting when  you are wrong is as much a part of 
real leadership as being right. Well done, Walter.

claptrap <clap trap.com> writes:

On Tuesday, 16 January 2024 at 20:38:37 UTC, Walter Bright wrote:
 https://github.com/dlang/dmd/pull/15715

 The only credit I can take is my constant challenges to it 
 caused it to evolve into a much better proposal.

Its nice that you're able to put a positive spin on it but the 
whole debacle has seriously damaged the community. You can keep 
telling yourself that the process should be difficult, that the 
fact that the dip was improved justifies all the drama, 
frustration and bad feelings that were generated. But it does not.

Plain simple fact is if you had been just trying to improve 1036, 
and been clear about that, then it would have been far less of a 
problem.

But what played out in the newsgroup looked to pretty much like 
you just couldn't let go of 1027 and would do almost anything to 
bring that back from the dead in lieu of 1036e.

You can say this is not what was happening from your point of 
view, but it certainly did not look that way. And even the most 
honest and self aware person would struggle to be fair and 
unbiased in such a situation. It's not a criticism of you, its 
just how the human brain works.

The problem is you are the gatekeeper, you shouldn't be in a 
position where you have a competing DIP and also still be the 
person who decides which one is accepted. It's a conflict of 
interest. And can only make things like your constant 
misunderstandings and hence misplaced criticism of 1036 look 
disingenuous.

So in the end, I hope you realise that accepting DIP1036 does not 
solve the underlying problems with how D is managed.

Dibyendu Majumdar <d.majumdar gmail.com> writes:

On Wednesday, 17 January 2024 at 10:08:28 UTC, claptrap wrote:
 The problem is you are the gatekeeper, you shouldn't be in a 
 position where you have a competing DIP and also still be the 
 person who decides which one is accepted. It's a conflict of 
 interest. And can only make things like your constant 
 misunderstandings and hence misplaced criticism of 1036 look 
 disingenuous.

 So in the end, I hope you realise that accepting DIP1036 does 
 not solve the underlying problems with how D is managed.

You are wrong. This is not a democracy. Walter is the BDFL for D, 
and he and core team decide what goes in.

There is no problem here. Debates and disagreements are healthy. 
Forking is also healthy. Attacking Walter and core team isn't.

claptrap <clap trap.com> writes:

On Wednesday, 17 January 2024 at 10:42:29 UTC, Dibyendu Majumdar 
wrote:
 On Wednesday, 17 January 2024 at 10:08:28 UTC, claptrap wrote:
 The problem is you are the gatekeeper, you shouldn't be in a 
 position where you have a competing DIP and also still be the 
 person who decides which one is accepted. It's a conflict of 
 interest. And can only make things like your constant 
 misunderstandings and hence misplaced criticism of 1036 look 
 disingenuous.

 So in the end, I hope you realise that accepting DIP1036 does 
 not solve the underlying problems with how D is managed.

 You are wrong. This is not a democracy. Walter is the BDFL for 
 D, and he and core team decide what goes in.

I never said anything at odds with that.


 There is no problem here. Debates and disagreements are 
 healthy. Forking is also healthy. Attacking Walter and core 
 team isn't.

You are niave and misinformed, alot of people, even core devs are 
not happy with how things are managed.

And I'm not attacking anyone, it's just debate and criticism.

Savy?

Dibyendu Majumdar <d.majumdar gmail.com> writes:

On Wednesday, 17 January 2024 at 10:54:07 UTC, claptrap wrote:
 You are niave and misinformed, alot of people, even core devs 
 are not happy with how things are managed.

 And I'm not attacking anyone, it's just debate and criticism.

Its people like you who are the problem.

In all the discussions, Walter always argues technical points, he 
never abuses or name calls people or attacks them personally.

It is the contributors job to convince not the other way round.

claptrap <clap trap.com> writes:

On Wednesday, 17 January 2024 at 10:58:44 UTC, Dibyendu Majumdar 
wrote:
 On Wednesday, 17 January 2024 at 10:54:07 UTC, claptrap wrote:
 You are niave and misinformed, alot of people, even core devs 
 are not happy with how things are managed.

 And I'm not attacking anyone, it's just debate and criticism.

 Its people like you who are the problem.

Are we in Noth Korea? People who dare to criticise the Dear 
Leader are "problems?

Will someone come round my house and put a bag over my head and 
drag me away?


 In all the discussions, Walter always argues technical points, 
 he never abuses or name calls people or attacks them personally.

Look, the reason there are two people to review the DIPs is so 
that Walter doesn't get to review his own DIPs. That process was 
set up to avoid conflict of interest. Avoiding conflict of 
interest is as much as about appearance is it is about actually 
avoiding it. The process needs to be open and to garner the trust 
of the people involved.

So unless something has changed Walter agreed with this. I'm 
saying the current situation with the SI DIPs was the same but 
actually worse.

You can't avoid that people will see alterior motives in what you 
do, just as its near impossible to be impartial if you also have 
a horse in the race.

What I'm saying has nothing to do with whether Walter can do 
whatever he wants, he can obviously, but that doesn't mean he 
should be immune from critisism in how things are run.

M.M. <matus email.cz> writes:

On Wednesday, 17 January 2024 at 11:40:31 UTC, claptrap wrote:
 In all the discussions, Walter always argues technical points, 
 he never abuses or name calls people or attacks them 
 personally.

 Look, the reason there are two people to review the DIPs is so 
 that Walter doesn't get to review his own DIPs. That process 
 was set up to avoid conflict of interest.

I understand your desire to have Walter more explicitly detached 
from decisions about his own DIPs. But, you are aware that 
DIP1027 was rejected, right?

claptrap <clap trap.com> writes:

On Wednesday, 17 January 2024 at 12:28:31 UTC, M.M. wrote:
 On Wednesday, 17 January 2024 at 11:40:31 UTC, claptrap wrote:
 In all the discussions, Walter always argues technical 
 points, he never abuses or name calls people or attacks them 
 personally.

 Look, the reason there are two people to review the DIPs is so 
 that Walter doesn't get to review his own DIPs. That process 
 was set up to avoid conflict of interest.

 I understand your desire to have Walter more explicitly 
 detached from decisions about his own DIPs. But, you are aware 
 that DIP1027 was rejected, right?

Yes but it was resurrected in response to the thread about 1036. 
It would be like arriving in court for a custody hearing only to 
find out the judge is in a relationship with your ex wife.

It should have not have happened like that.

It beggars belief that nobody seems to understand that.

claptrap <clap trap.com> writes:

On Wednesday, 17 January 2024 at 12:28:31 UTC, M.M. wrote:
 On Wednesday, 17 January 2024 at 11:40:31 UTC, claptrap wrote:
 In all the discussions, Walter always argues technical 
 points, he never abuses or name calls people or attacks them 
 personally.

 Look, the reason there are two people to review the DIPs is so 
 that Walter doesn't get to review his own DIPs. That process 
 was set up to avoid conflict of interest.

 I understand your desire to have Walter more explicitly 
 detached from decisions about his own DIPs. But, you are aware 
 that DIP1027 was rejected, right?

It's more that he should not have used the talk about 1036 to 
bring back his own DIP that had already been rejected. Not when 
he's the final judge. Is disrespectful and unfair.

M.M. <matus email.cz> writes:

On Wednesday, 17 January 2024 at 12:41:17 UTC, claptrap wrote:
 On Wednesday, 17 January 2024 at 12:28:31 UTC, M.M. wrote:
 On Wednesday, 17 January 2024 at 11:40:31 UTC, claptrap wrote:
 In all the discussions, Walter always argues technical 
 points, he never abuses or name calls people or attacks them 
 personally.

 Look, the reason there are two people to review the DIPs is 
 so that Walter doesn't get to review his own DIPs. That 
 process was set up to avoid conflict of interest.

 I understand your desire to have Walter more explicitly 
 detached from decisions about his own DIPs. But, you are aware 
 that DIP1027 was rejected, right?

 It's more that he should not have used the talk about 1036 to 
 bring back his own DIP that had already been rejected. Not when 
 he's the final judge. Is disrespectful and unfair.

I myself saw his comparison of DIP1027 to DIP1036, YAIDIP, and 
DIP1036e as demonstrating his overall general wish for "simple 
solutions" with "little corner and special cases"; in this view, 
bringing back DIP1027 demonstrates this part very concretely 
(instead of abstractly). But I certainly see that using your 
lenses the overall approach of Walter can be seen as pushing for 
own solution (and not arguing for a general simpler solution).

I personally thought that the discussion could have been swifter 
(but then again, we would perhaps end up with DIP1036 instead of 
DIP1036e) and, somehow, more open to listening (well, at least 
from the how-it-looks-like-on-the-forum point of view).

Overall, I understand that there are people frustrated with the 
overall situation 
(communication/discussion/rules-of-contribution/etc) how dlang is 
rung, and I also understand that some feel this is a long-term 
accumulation of frustrations. (I would just like to point out 
that DLF is acknowledging much of that and commits to 
improvements. I understand that some do not see this.) But 
talking about principles and communication, I think that refusing 
to write a documentation for a new feature is not the nicest way 
to communicate. (While I understand this all came from a 
culmination of frustration over previous discussions on a related 
feature.)

bachmeier <no spam.net> writes:

On Wednesday, 17 January 2024 at 14:06:28 UTC, M.M. wrote:

 I myself saw his comparison of DIP1027 to DIP1036, YAIDIP, and 
 DIP1036e as demonstrating his overall general wish for "simple 
 solutions" with "little corner and special cases"; in this 
 view, bringing back DIP1027 demonstrates this part very 
 concretely (instead of abstractly). But I certainly see that 
 using your lenses the overall approach of Walter can be seen as 
 pushing for own solution (and not arguing for a general simpler 
 solution).

That was my interpretation too. I didn't read all of the posts, 
but my impression is that Walter didn't fully understand what 
people wanted to do with SQL, and it's not reasonable to expect 
anyone to understand every use for a programming language. It's 
frustrating, but communication is difficult when it involves 
other humans.

claptrap <clap trap.com> writes:

On Wednesday, 17 January 2024 at 14:06:28 UTC, M.M. wrote:
 On Wednesday, 17 January 2024 at 12:41:17 UTC, claptrap wrote:
 On Wednesday, 17 January 2024 at 12:28:31 UTC, M.M. wrote:
 On Wednesday, 17 January 2024 at 11:40:31 UTC, claptrap wrote:



 I personally thought that the discussion could have been 
 swifter (but then again, we would perhaps end up with DIP1036 
 instead of DIP1036e)

I agree with most of what you've said.

However when someone says, "yes it was acrimonious but at least 
it led to a better DIP" they're brushing over fact that it could 
have been handled differently at still got the same result.

If youre telling youself the ends justify the means then you 
better think harder about what your doing.

GrimMaple <grimmaple95 gmail.com> writes:

I was trying to refrain from this forum, but oh boy.

On Wednesday, 17 January 2024 at 10:58:44 UTC, Dibyendu Majumdar 
wrote:
 In all the discussions, Walter always argues technical points, 
 he never abuses or name calls people or attacks them personally.

In the same sense, you can argue that Ferrari F40 is a bad car, 
because it can't go off road much. It's a perfectly technical 
standpoint that a lot of other cars implement - you have Jeeps 
and Land Rovers that do a much better job offroading. On the 
other side, you can argue that Land Rovers are bad cars, because 
they don't go very fast. And that's a perfectly technical 
standpoint that a lot of other cars implement -- for example, the 
Ferrari F40. You see what I did there?

In a world where different goals are possible, you can always 
find a technical point to argue. If it's ` nogc` it's hard to 
use. If it's backed by the GC, then it's not ` nogc`. And I have 
repeatedly stated this - this "technical" arguing is just used to 
stall useful contributions that Walter personally dislikes, 
doesn't understand, or doesn't care to understand. It took what, 
half a year of arguing and an entire fork for Walter to finally 
step in and _do something_? Imagine if we didn't have to do all 
that and instead the job was just done. Would be a dream to live 
in.

I would even go as far as argue that "technical debate" is the 
root of all evil. Unless there is a set of rules you can always 
go back to. Eg, if D had a rule something like "GC is not an 
arguing point", there would be less arguing. If D embraced GC and 
centered itself around it, there would be less arguing. If there 
were any guidlines to contributing, there would be less arguing. 
In my humble opinion, we shouldn't spend our lives arguing about 
"technical points", unless there is a clear error in 
implementation. Instead, we should focus on some goal, which D 
doesn't even have in the first place.

DrDread <DrDread cheese.com> writes:

On Wednesday, 17 January 2024 at 10:58:44 UTC, Dibyendu Majumdar 
wrote:
 On Wednesday, 17 January 2024 at 10:54:07 UTC, claptrap wrote:
 You are niave and misinformed, alot of people, even core devs 
 are not happy with how things are managed.

 And I'm not attacking anyone, it's just debate and criticism.

 Its people like you who are the problem.

 In all the discussions, Walter always argues technical points, 
 he never abuses or name calls people or attacks them personally.

 It is the contributors job to convince not the other way round.

see, there's your problem. it's not the contributors job, they do 
this in their free time.
if you want contributions you simply cannot act like that.

Mike Parker <aldacron gmail.com> writes:

On Thursday, 18 January 2024 at 10:54:44 UTC, DrDread wrote:
 On Wednesday, 17 January 2024 at 10:58:44 UTC, Dibyendu

 It is the contributors job to convince not the other way round.

 see, there's your problem. it's not the contributors job, they 
 do this in their free time.
 if you want contributions you simply cannot act like that.

Wrong. Spending your free time on a contribution does not 
automagically make it correct, suitable, or worth having. Every 
contribution has to be judged on its merits, not whether or not 
it was done on a salaried or volunteer basis.

The question should never be, "Why not merge this?" but always 
"Why merge this?".

DrDread <DrDread cheese.com> writes:

On Thursday, 18 January 2024 at 11:02:29 UTC, Mike Parker wrote:
 On Thursday, 18 January 2024 at 10:54:44 UTC, DrDread wrote:
 On Wednesday, 17 January 2024 at 10:58:44 UTC, Dibyendu

 It is the contributors job to convince not the other way 
 round.

 see, there's your problem. it's not the contributors job, they 
 do this in their free time.
 if you want contributions you simply cannot act like that.

 Wrong. Spending your free time on a contribution does not 
 automagically make it correct, suitable, or worth having. Every 
 contribution has to be judged on its merits, not whether or not 
 it was done on a salaried or volunteer basis.

 The question should never be, "Why not merge this?" but always 
 "Why merge this?".

you are still missing the point. it's not about rejecting a 
proposal, it's about how the contributors are treated. how the 
'management' wastes the time of contributors by not engaging 
early.

Dibyendu Majumdar <d.majumdar gmail.com> writes:

On Thursday, 18 January 2024 at 11:07:36 UTC, DrDread wrote:

 you are still missing the point. it's not about rejecting a 
 proposal, it's about how the contributors are treated. how the 
 'management' wastes the time of contributors by not engaging 
 early.

This is an OpenSource project - everyone works on such projects 
on a voluntary basis.

By your argument, a contributor wastes management's time by 
contributing because someone has to then look at it no matter how 
bad it is.

In a project like this, everything happens because someone likes 
what you did, and wants to help, there is no obligation for 
anyone to engage with anyone.

Siarhei Siamashka <siarhei.siamashka gmail.com> writes:

On Thursday, 18 January 2024 at 11:37:51 UTC, Dibyendu Majumdar 
wrote:
 This is an OpenSource project - everyone works on such projects 
 on a voluntary basis.

OpenSource does not imply non-commercial. In fact, many people 
have business interests in one way or another. And it would be 
great to have more jobs and successful profitable companies in 
the D language ecosystem.

Serg Gini <kornburn yandex.ru> writes:

On Thursday, 18 January 2024 at 11:37:51 UTC, Dibyendu Majumdar 
wrote:
 This is an OpenSource project - everyone works on such projects 
 on a voluntary basis.

Open Source model is not working in huge products usually..
Greatest project sponsored by corps. Many FOSS done by RedHat, 
Google, Facebook and other companies.

Some academics/hobby devs could add something of course, but the 
most significant changes usually leads to highly paid devs.

Same with D. Many devs who work on Weka and Symmetry contributing 
to D, because Weka and Symmetry need those changes/fixes and 
interested in overall D improvements. Previously there were other 
companies as well (AdRoll, Sociomatic).

Business adoption is crucial for the language.
And for example Ocaml - has much better adoption than D. D really 
needs to improve this part.

claptrap <clap trap.com> writes:

On Thursday, 18 January 2024 at 11:37:51 UTC, Dibyendu Majumdar 
wrote:
 On Thursday, 18 January 2024 at 11:07:36 UTC, DrDread wrote:

 In a project like this, everything happens because someone 
 likes what you did, and wants to help, there is no obligation 
 for anyone to engage with anyone.

I have no obligation to be nice to my freinds.

But if I'm not I will quickly end up with none.

See how that works?

Dibyendu Majumdar <d.majumdar gmail.com> writes:

On Thursday, 18 January 2024 at 13:04:09 UTC, claptrap wrote:
 On Thursday, 18 January 2024 at 11:37:51 UTC, Dibyendu Majumdar 
 wrote:
 On Thursday, 18 January 2024 at 11:07:36 UTC, DrDread wrote:

 In a project like this, everything happens because someone 
 likes what you did, and wants to help, there is no obligation 
 for anyone to engage with anyone.

 I have no obligation to be nice to my freinds.

 But if I'm not I will quickly end up with none.

 See how that works?

It only proves my point, because the only people not nice on 
these forums are these so called contributors, many of who 
actually have made no contribution but are happy to make a lot of 
demands as if its their right!

"H. S. Teoh" <hsteoh qfbox.info> writes:

On Thu, Jan 18, 2024 at 02:02:56PM +0000, Dibyendu Majumdar via Digitalmars-d
wrote:
[...]
 It only proves my point, because the only people not nice on these
 forums are these so called contributors, many of who actually have
 made no contribution but are happy to make a lot of demands as if its
 their right!

That's irrelevant.  Some of the people who left recently were *very*
active contributors, who have had a lot of work merged and who did a lot
of user support on their own free time.  We're not talking here about
the regular whiners who show up out of nowhere with strange or
unreasonable demands while not lifting a finger themselves. (Personally
I just hit the delete button for those, it's not worth my time.)  We're
talking about people who have had a long history of contributing to D
getting frustrated with the way they were treated *in spite of having
actively contributed* to D.

Whole different kettle o' fish here.


T

-- 
My program has no bugs! Only unintentional features...

Dibyendu Majumdar <d.majumdar gmail.com> writes:

On Thursday, 18 January 2024 at 15:03:09 UTC, H. S. Teoh wrote:
 That's irrelevant.  Some of the people who left recently were 
 *very* active contributors, who have had a lot of work merged 
 and who did a lot of user support on their own free time.  
 We're not talking here about the regular whiners who show up 
 out of nowhere with strange or unreasonable demands while not 
 lifting a finger themselves. (Personally I just hit the delete 
 button for those, it's not worth my time.)  We're talking about 
 people who have had a long history of contributing to D getting 
 frustrated with the way they were treated *in spite of having 
 actively contributed* to D.

Please would you elaborate on what you mean by how they were 
treated?

Admittedly I am not active here so I may be missing things, but I 
don't see anyone being mistreated here by Walter.

If you mean that contributions are not being looked at - I think 
it goes back to the fact this is volunteer project and everyone 
works on what they want to work on. In this setup to get someone 
else to take an interest in your contribution is hard! That's how 
it is.

The fact that someone looks at your contribution seriously at all 
is itself a miracle.

I don't see a solution - unless you want to fund D so that a 
large team can be hired!

Don Allen <donaldcallen gmail.com> writes:

On Thursday, 18 January 2024 at 15:27:34 UTC, Dibyendu Majumdar 
wrote:
 On Thursday, 18 January 2024 at 15:03:09 UTC, H. S. Teoh wrote:
 That's irrelevant.  Some of the people who left recently were 
 *very* active contributors, who have had a lot of work merged 
 and who did a lot of user support on their own free time.  
 We're not talking here about the regular whiners who show up 
 out of nowhere with strange or unreasonable demands while not 
 lifting a finger themselves. (Personally I just hit the delete 
 button for those, it's not worth my time.)  We're talking 
 about people who have had a long history of contributing to D 
 getting frustrated with the way they were treated *in spite of 
 having actively contributed* to D.

 Please would you elaborate on what you mean by how they were 
 treated?

 Admittedly I am not active here so I may be missing things, but 
 I don't see anyone being mistreated here by Walter.

 If you mean that contributions are not being looked at - I 
 think it goes back to the fact this is volunteer project and 
 everyone works on what they want to work on. In this setup to 
 get someone else to take an interest in your contribution is 
 hard! That's how it is.

 The fact that someone looks at your contribution seriously at 
 all is itself a miracle.

 I don't see a solution - unless you want to fund D so that a 
 large team can be hired!

And even that is not guaranteed to work. The kinds of conflicts 
we are observing here occur in businesses where everyone is a 
paid employee. People get upset about how they are being treated, 
or perceive how they are being treated, and they leave.

In addition to the real problems cited by you and others, I think 
there is also a generational factor. Walter is an older person; I 
can say that because I'm even further to the right on that axis, 
plus he's a classic engineer (that's a compliment). The more 
experience you have, the more you know about what can go wrong, 
so the tendency is to slow down, make sure things are thought 
through.

The bright young folks are full of energy and ideas and they like 
to move fast.

Combine these two characteristics well and you've really got 
something. This is much like Modern Portfolio Theory, where you 
can build a portfolio from multiple risky securities that is much 
less risky than any of them, due to how covariance is computed. 
It's also a "whole is greater than the sum of the parts" 
phenomenon.

It's clear that this project has not done a good enough job of 
combining the generations to get the best from both. There are 
issues, shortcomings, on both sides that I don't need to repeat 
-- they've been discussed here ad nauseam. It's vitally important 
that everyone left on the main D project try to learn from this 
latest blowup to avoid a repeat performance. No childish 
name-calling, proper attention paid to the work of people trying 
to contribute (which does not mean accepting their work just 
because they are well intentioned), etc. This is a necessary 
condition for this project to achieve more success than it has, 
however you define "success".

"H. S. Teoh" <hsteoh qfbox.info> writes:

On Thu, Jan 18, 2024 at 03:27:34PM +0000, Dibyendu Majumdar via Digitalmars-d
wrote:
 On Thursday, 18 January 2024 at 15:03:09 UTC, H. S. Teoh wrote:
 That's irrelevant.  Some of the people who left recently were *very*
 active contributors, who have had a lot of work merged and who did a
 lot of user support on their own free time.  We're not talking here
 about the regular whiners who show up out of nowhere with strange or
 unreasonable demands while not lifting a finger themselves.
 (Personally I just hit the delete button for those, it's not worth
 my time.)  We're talking about people who have had a long history of
 contributing to D getting frustrated with the way they were treated
 *in spite of having actively contributed* to D.
 

 
 Please would you elaborate on what you mean by how they were treated?

I've already said this before elsewhere, but in short: an eager
contributor shows up, submits PRs which are merged, then is given commit
access to Phobos. He and I worked together to clear up Phobos' backed-up
PR queue.  Then suddenly out of the blue, Andrei shows up after months
of being MIA (or just giving 1-word responses) and drops on us like a
ton of bricks, saying that we did this and that wrong, we let things
through that shouldn't have been let through, Good Work vs. Great Work,
etc..  A bunch of PRs were reverted.

Now, perhaps Andrei was right, and what we did wasn't up to the D
leadership's standard.  But here's the point: we were never informed
about this beforehand.  We were not told what exactly was expected of
us.  There were no guidelines, no list of things to watch out for, no
overall direction that would guide our decisions, nothing.  Just
unwritten rules that we were expected to know, perhaps by clairvoyance,
lest the fury descend upon us from on high.

In the aftermath, said contributor walked away. Who could blame him?  I
stayed, but greatly scaled back my own contributions.  Not because I was
upset (I wasn't), but I thought, since my work wasn't good enough, I
should just let somebody else more qualified to step up.  Guess what?
Nobody did.  In the end, the DLF had to pay someone to work on the PR
queues.  I guess that's about the only way anyone would be willing to
work under such circumstances.

This isn't the only time something like this happened, it's just the one
I know better because I was personally involved. The same pattern has
been repeated throughout the time I was with D.  Clearly, something
isn't going right here.


[...]
 I don't see a solution - unless you want to fund D so that a large
 team can be hired!

This is perhaps the crux of it.  We're trying to run an open source,
volunteer-driven project -- and a *small* one at that -- like a large,
proprietary enterprise, and it's not working very well.  Andrei's
reaction above?  Not entirely unexpected in a large corporation.  You're
being paid to do the work, so you just swallow it and do your job.  But
in a volunteer-driven open-source project?  Well, we're seeing the
consequences unfolding right before our eyes.


T

-- 
Nearly all men can stand adversity, but if you want to test a man's
character, give him power. -- Abraham Lincoln

Walter Bright <newshound2 digitalmars.com> writes:

Andrei left us years ago. Complaining about him is pointless.

Andrei is a first rate programmer. If he says some work is not good enough, 
asking him "why" and "how can I make it good enough" is a much more worthwhile 
reaction than getting angry and leaving.

I know I've told some contributors their work isn't good enough, and tried to 
explain why. Some have, as a result, greatly improved the quality of their 
contributions. Some have gotten angry and left.

I don't miss the latter.

All of us can improve our code, and should be willing to objectively consider 
suggestions for improvement. My talk at DConf2023 was all about my own 
discoveries on how to write better code. Those who watch my PRs will see a 
continual progression on implementing them.

When I was in my 20s, I thought the code I wrote was god's gift to the world. 
The very idea is laughable to me now.

DMD/Phobos/etc is a large, complex project. We simply cannot afford to accept 
low quality contributions, as the project will become unmaintainable. Anyone 
should be proud when their contributions meet our high standards. We're willing 
to help those who do not get better - but if they don't want help, I'm sorry 
about that, but that's the way it goes.

Note that I am *not* saying that everyone who has left has left for that
reason. 
There have been many reasons.

Adam Wilson <flyboynw gmail.com> writes:

On Saturday, 20 January 2024 at 21:11:20 UTC, Walter Bright wrote:
 DMD/Phobos/etc is a large, complex project. We simply cannot 
 afford to accept low quality contributions, as the project will 
 become unmaintainable. Anyone should be proud when their 
 contributions meet our high standards. We're willing to help 
 those who do not get better - but if they don't want help, I'm 
 sorry about that, but that's the way it goes.

I think we need to specify what we mean when we say "low quality 
contributions" as opinions on the subject vary drastically. 
Quality here would be defined, in order, as:
- Correctness (No obvious bugs, unittests pass, etc.)
- Completeness (Does the code cover all know/specified cases)
- Legibility (Can the average engineer understand the code? This 
isn't the Obfuscated C Contest.)

Sadly, because it's easier bikeshed, especially when the reviewer 
doesn't actually understand the code, most code reviews turn into 
nit-picks focusing on sub-optimal but ultimately insignificant 
deviations from the reviewers stylistic preferences, all in the 
name of "legibility". The single best way to derail a 
conversation on code reviews is to bring up the topic of ... line 
length. Many an epic review rant has been launched on the best 
line length. To hear the reviewer tell it, line length violations 
are the equivalent of ritually sacrificing kittens, or some other 
equally heinous crime.

But aside from personal preference and varied screen widths, line 
length is irrelevant to any rational definition of quality. The 
compiler certainly does not care about it, it's a pure human 
preference that makes no difference in the slightest to the 
generated binary. The best argument you can make is that they 
increase the readability of the code, which is at best a minor 
tributary of understanding the code. Yes, organizing the code in 
a more readable format will nominally improve legibility, but 
many Obfuscated C programs have no trouble adhering to the sacred 
80 character line limit. I will (and have frequently in the past) 
merged code that violated the Holy Character Limit, because the 
code was still legible.

Even more importantly, nitpicking greatly increases the noise of 
a code review. We all have a story from our past where we missed 
the one important review item that was drowning in a sea of 
nitpicks. Improve the signal-to-noise ratio, and the quality of 
the code, as defined above, will naturally improve.

However, there is another reason to avoid nitpicking. It improves 
the our relationship with those who conduct the reviews. 
Nitpicking is often used as a tool to stall out or otherwise 
derail a PR that the reviewer either doesn't understand or 
doesn't *want* to understand, usually because they don't want to 
see it merged for whatever reason. And given recent events in D, 
I think this is an important point. One solid and easily 
achievable way to improve our relationships with one another is 
reduce the amount of nitpicking we do of others code. I think we 
forget that the implemented will naturally see review comments 
(critiques) as failures, and seeing a blizzard of review comments 
is incredibly demoralizing.

For a more in depth look at the problems with nitpicking in 
reviews, I highly recommend [this 
article](https://blog.danlew.net/2021/02/23/stop-nitpicking-in-code-reviews/)
by Dan Lew.

And yes, if I get a quality PR that has a line of code with 121 
characters, I am merging it, without comment, without hesitation, 
and with a smile on my face, because somebody saw fit to donate 
their time to help me out.

Dom DiSc <dominikus scherkl.de> writes:

On Sunday, 21 January 2024 at 11:13:41 UTC, Adam Wilson wrote:
 I think we need to specify what we mean when we say "low 
 quality contributions" as opinions on the subject vary 
 drastically. Quality here would be defined, in order, as:
 - Correctness (No obvious bugs, unittests pass, etc.)
 - Completeness (Does the code cover all know/specified cases)
 - Legibility (Can the average engineer understand the code? 
 This isn't the Obfuscated C Contest.)

I fully agree.

 Sadly, because it's easier bikeshed, especially when the 
 reviewer doesn't actually understand the code, most code 
 reviews turn into nit-picks focusing on sub-optimal but 
 ultimately insignificant deviations from the reviewers 
 stylistic preferences, all in the name of "legibility". The 
 single best way to derail a conversation on code reviews is to 
 bring up the topic of ... line length.

Oh please.
Everybody submitting a PR can easily run dfmt on it. This done 
there should be no more "too long lines", "multiple expressions 
in one line", "not correct indented code", "curly braces not on 
their own line", etc. pp.
If someone submit PRs without running dfmt, (s)he should be 
advised to do so. End of discussion.

matheus <matheus gmail.com> writes:

On Sunday, 21 January 2024 at 12:35:53 UTC, Dom DiSc wrote:
 ...
 Oh please.
 Everybody submitting a PR can easily run dfmt on it. This done 
 there should be no more "too long lines", "multiple expressions 
 in one line", "not correct indented code", "curly braces not on 
 their own line", etc. pp.
 If someone submit PRs without running dfmt, (s)he should be 
 advised to do so. End of discussion.
 ...

I always thought that the code should be accompanying with a 
style file (Or markup?), something like HTML and CSS, and each 
one could defined the style they are pleased, for example I 
prefer curly braces on their on line, like 1TBS/OTBS style, and 
sometimes for _simple_ things I do prefer multiple expressions in 
one line.

Matheus.

"Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:

On 22/01/2024 1:35 AM, Dom DiSc wrote:
     Sadly, because it's easier bikeshed, especially when the reviewer
     doesn't actually understand the code, most code reviews turn into
     nit-picks focusing on sub-optimal but ultimately insignificant
     deviations from the reviewers stylistic preferences, all in the name
     of "legibility". The single best way to derail a conversation on
     code reviews is to bring up the topic of ... line length.
 
 Oh please. Everybody submitting a PR can easily run dfmt on it. This 
 done there should be no more "too long lines", "multiple expressions in 
 one line", "not correct indented code", "curly braces not on their own 
 line", etc. pp. If someone submit PRs without running dfmt, (s)he should 
 be advised to do so. End of discussion.

Yes, that has been added to the PhobosV3 proposal by Adam.

I also suggested that we automate it as part of the CI. Because who has 
time to care about white space at the end of a line? No thanks.

Meta <jared771 gmail.com> writes:

On Sunday, 21 January 2024 at 17:37:41 UTC, Richard (Rikki) 
Andrew Cattermole wrote:
 On 22/01/2024 1:35 AM, Dom DiSc wrote:
     Sadly, because it's easier bikeshed, especially when the 
 reviewer
     doesn't actually understand the code, most code reviews 
 turn into
     nit-picks focusing on sub-optimal but ultimately 
 insignificant
     deviations from the reviewers stylistic preferences, all 
 in the name
     of "legibility". The single best way to derail a 
 conversation on
     code reviews is to bring up the topic of ... line length.
 
 Oh please. Everybody submitting a PR can easily run dfmt on 
 it. This done there should be no more "too long lines", 
 "multiple expressions in one line", "not correct indented 
 code", "curly braces not on their own line", etc. pp. If 
 someone submit PRs without running dfmt, (s)he should be 
 advised to do so. End of discussion.

 Yes, that has been added to the PhobosV3 proposal by Adam.

 I also suggested that we automate it as part of the CI. Because 
 who has time to care about white space at the end of a line? No 
 thanks.

Yes, yes, and yes. At work we have a linter that IS integrated 
into the CI pipeline, and a formatter that is NOT, for some 
unfathomable reason. Every time one of my PRs fails the CI 
pipeline because I forgot to run the formatting tool before 
pushing, I want to scream. Just automate it and a whole class of 
PR nitpicks/arguments disappears, and everyone is better off.

kdevel <kdevel vogtner.de> writes:

On Sunday, 21 January 2024 at 19:20:21 UTC, Meta wrote:
 [...] I forgot to run the formatting tool before pushing, I 
 want to scream. Just automate it and a whole class of PR 
 nitpicks/arguments disappears, and everyone is better off.

What about code which is more art than craft?

     this(int a, int aa, int aaa, int aaaa, int aaaaa)
     {
             this.a = a;
            this.aa = aa;
           this.aaa = aaa;
          this.aaaa = aaaa;
         this.aaaaa = aaaaa;
     }

     double carefullyHandAlignedIndentation(double 
x________________________,
                                            double 
y________________________,
                                            double 
z________________________)
     {
         return 0;
     }

dfmt --brace_style otbs produces

     this(int a, int aa, int aaa, int aaaa, int aaaaa) {
         this.a = a;
         this.aa = aa;
         this.aaa = aaa;
         this.aaaa = aaaa;
         this.aaaaa = aaaaa;
     }

     double carefullyHandAlignedIndentation(double 
x________________________,
             double y________________________, double 
z________________________) {
         return 0;
     }

"Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:

If you need to disable dfmt for a block of code, disable it.

https://github.com/dlang-community/dfmt?tab=readme-ov-file#disabling-formatting

```d
void main(string[] args)
{
     bool optionOne, optionTwo, optionThree;

     // dfmt has no way of knowing that "getopt" is special, so it wraps the
     // argument list normally
     getopt(args, "optionOne", &optionOne, "optionTwo", &optionTwo, 
"optionThree", &optionThree);

     // dfmt off
     getopt(args,
         "optionOne", &optionOne,
         "optionTwo", &optionTwo,
         "optionThree", &optionThree);
     // dfmt on
}
```

Walter Bright <newshound2 digitalmars.com> writes:

Many of my PRs have been nitpicked. I just fix them, it's easier than arguing 
about it.

Elias Batek (0xEAB) <desisma heidel.beer> writes:

On Sunday, 21 January 2024 at 17:12:37 UTC, Walter Bright wrote:
 Many of my PRs have been nitpicked. I just fix them, it's 
 easier than arguing about it.

I think, I said this one Discord a while ago, it’s usually so 
much quicker to just submit a cleanup patch/PR than trying to 
push the nits through the review of the main PR.

If it isn’t something substantial that the original author should 
be aware of, doing so is easier and will save everyone time.

Mike Parker <aldacron gmail.com> writes:

On Thursday, 18 January 2024 at 15:03:09 UTC, H. S. Teoh wrote:

 button for those, it's not worth my time.)  We're talking about 
 people who have had a long history of contributing to D getting 
 frustrated with the way they were treated *in spite of having 
 actively contributed* to D.

I'm going to leave a few paragraphs here about this and then I'll 
say nothing more about it. And I want to be clear that these are 
my personal thoughts, not any sort of "official" thing on behalf 
of anyone in the DLF.

Whatever went on in the past, we have been actively working to 
make things better. When Grim posted his rant about deprecations, 
we implemented a new deprecation policy and actually started 
reverting deprecations. And though I know he has accused us of 
making no progress on the gripes and wishes, we actually have 
done so. That it hasn't been publicized is on me. Updating the 
list with the status of the points we've addressed is on my TODO 
list, but it's been a low priority for me.

After Adam made it known to me in an email last year how he 
really felt, I put him at the top of my list when I started 
reaching out to long-time contributors for one-on-one chats. We 
brought him into the meetings and he got Walter to accept the 
 standalone feature early on. When he brought in 1036e, Walter 
agreed to give it a fair evaluation. Adam was unhappy that Walter 
wanted a spec, so Atila agreed to put the editions proposal on 
hold to get it done (and please, let's not rehash the argument 
about reading code vs. writing specs).

All of this despite new features being on hold while we are 
focused on stabilization *and* editions being a very high 
priority. And despite the verbal abuse that Adam heaped on us in 
our meetings and repeatedly in the Discord server.

So please excuse me for being blunt when I say it's getting 
really tiresome hearing that we treated Adam badly here. Again, 
whatever happened in the past, that was not what was happening in 
this situation. He was at the table, actively being listened to, 
and actively providing feedback in our meetings.

I was extremely disappointed when he decided to follow the path 
he chose. I had high hopes that we were at the beginning of a new 
stage in our relationship with him. I like Adam, I admire the 
volume of code he has produced over the years, and I appreciate 
the untold lines of text he's written and hours he's spent 
helping new D programmers find their way.

I just wanted to leave this here as my personal perspective on 
what's happened the past few weeks. I have no interest in 
debating anyone about this and I'm not going to engage with any 
rebuttals.

We have work to do, and this topic has been beaten to death ten 
times over by now. Contributors have felt disrespected and 
ignored. We hear you. We all recognize and accept that we need to 
take steps to prevent this sort of thing from happening again in 
the future and provide the means to resolve it if it does. 
Reiterating and rehashing the accusations again and again is just 
going to keep these threads mired in multiple pages of points and 
counterpoints while adding no value to the conversation, doing 
nothing to help move us forward, and just filling the place with 
negative vibes.

Contributor relations need to improve. We get it. So I implore 
everyone to please lay this to rest and let's get on with the 
business of making things better for all of us.

"H. S. Teoh" <hsteoh qfbox.info> writes:

On Thu, Jan 18, 2024 at 04:31:11PM +0000, Mike Parker via Digitalmars-d wrote:
 On Thursday, 18 January 2024 at 15:03:09 UTC, H. S. Teoh wrote:
 
 button for those, it's not worth my time.)  We're talking about
 people who have had a long history of contributing to D getting
 frustrated with the way they were treated *in spite of having
 actively contributed* to D.


[...]
 So please excuse me for being blunt when I say it's getting really
 tiresome hearing that we treated Adam badly here.

[...]

I wasn't referring only to Adam. There's also been a long line of
others, like Wilzbach, berni44, Mihails Strasuns, bearophile, etc..  If
it were only Adam, I'd have written it off as something specific to him,
or other incidental factors. But when we have a long line of previously
active, productive contributors walk away, we have a problem.

We should be growing the number of contributors, like with Linux kernel
developers, not bleeding them.


T

-- 
Why do conspiracy theories always come from the same people??

Dibyendu Majumdar <d.majumdar gmail.com> writes:

On Thursday, 18 January 2024 at 17:38:44 UTC, H. S. Teoh wrote:
 But when we have a long line of previously active, productive 
 contributors walk away, we have a problem.

 We should be growing the number of contributors, like with 
 Linux kernel developers, not bleeding them.

I feel that with any project, there will never be the same set of 
contributors over a longish period of time. This is true even in 
commercial organizations, where people come and go. In fact the 
health of the eco system is actually that no one is 
indispensable. Organizations will often fire talented people who 
are disruptive.

I feel D has been remarkably successful in attracting 
contributors.

"H. S. Teoh" <hsteoh qfbox.info> writes:

On Thu, Jan 18, 2024 at 05:49:22PM +0000, Dibyendu Majumdar via Digitalmars-d
wrote:
 On Thursday, 18 January 2024 at 17:38:44 UTC, H. S. Teoh wrote:
 But when we have a long line of previously active, productive
 contributors walk away, we have a problem.
 
 We should be growing the number of contributors, like with Linux
 kernel developers, not bleeding them.
 

 
 I feel that with any project, there will never be the same set of
 contributors over a longish period of time. This is true even in
 commercial organizations, where people come and go. In fact the health
 of the eco system is actually that no one is indispensable.
 Organizations will often fire talented people who are disruptive.

The way D is being run, it *should* have been a commercial organization
where the leadership is free to impose whatever arbitrary standards they
want to, and the employees either suck it up or get fired. It'd have
been more successful that way.

Unfortunately, this style of management isn't working very well in a
volunteer-driven open source project. Our history proves this.


 I feel D has been remarkably successful in attracting contributors.

Because D, the language, is just *that* good.  It's very close to my
ideal of what a programming language ought to be.  Which is why I'm
still here.  I want to see D succeed.  If D were any less, I'd have
walked away too.  I could be doing a lot of other things with my free
time.


T

-- 
Klein bottle for rent ... inquire within. -- Stephen Mulraney

aberba <karabutaworld gmail.com> writes:

On Thursday, 18 January 2024 at 17:49:22 UTC, Dibyendu Majumdar 
wrote:
 On Thursday, 18 January 2024 at 17:38:44 UTC, H. S. Teoh wrote:
 But when we have a long line of previously active, productive 
 contributors walk away, we have a problem.

 We should be growing the number of contributors, like with 
 Linux kernel developers, not bleeding them.

 I feel that with any project, there will never be the same set 
 of contributors over a longish period of time. This is true 
 even in commercial organizations, where people come and go. In 
 fact the health of the eco system is actually that no one is 
 indispensable. Organizations will often fire talented people 
 who are disruptive.

 I feel D has been remarkably successful in attracting 
 contributors.

Naa,man, I doubt you have any idea the background story of this 
whole conversation. I get that you're pumped up about D, but 
you're missing a lot of context.

Maybe let those who have context of the history hash it out 
themselves. You've already stated you're not active in here.

Mike admits they're working on improving things. I've been on and 
off here since 2014 and I've seen quite a bit. I'm kinda sad a 
number of the people who left were once super active in the 
community. I hope we find a way to improve the experience of 
contributors. Imagine where the community would be if we had all 
those guys still actively participating in the community.

As much as it might frustrate some folks here, every leader gotta 
deal with complaints...and will need to listen, communicate, 
admit (when necessary), and assure memebers of the willingness to 
improve. That alone something. We're not robots, we're humans, so 
the social side of managing a community matters. I however would 
urge doing that without throwing insults or being harsh.

Big shout out to Mike for the always calming things down in this 
regard.

Walter Bright <newshound2 digitalmars.com> writes:

People leave for many reasons. Often their situation and interests change, and 
they move on, just like the employees of any company. I'm glad they were here 
when they were, and wish them well in their next endeavor.

Of course, we also have several "lifers", which are great!

BTW, I do not accept any compensation from the DLF, and pay my own way to the 
conferences.

matheus <matheus gmail.com> writes:

On Thursday, 18 January 2024 at 17:38:44 UTC, H. S. Teoh wrote:
 ...
 I wasn't referring only to Adam. There's also been a long line 
 of others, like Wilzbach, berni44, Mihails Strasuns, 
 bearophile, etc..  If it were only Adam, I'd have written it ...

Jonathan Marler which by the way was trying to implement a String 
interpolation with tuples, and I think that was the last straw.

Matheus.

Adam D Ruppe <destructionator gmail.com> writes:

I unsubscribed from this forum, since I find it to make me angry 
and not lead anywhere productive, but people linked me to this so 
I'll give one more reply to set the record straight.

There's a ST:TNG scene that comes to mind relating to all this:

https://www.youtube.com/watch?v=Owyj_5TuHQw

"It's not you I hate, Cardassian. I hate what I became because of 
you."

I used to be nice to people online. I used to not cuss online. I 
kinda miss the old me.

On Thursday, 18 January 2024 at 16:31:11 UTC, Mike Parker wrote:
 Adam was unhappy that Walter wanted a spec, so Atila agreed to 
 put the editions proposal on hold to get it done (and please, 
 let's not rehash the argument about reading code vs. writing 
 specs).

It was never about reading code vs writing specs. Let's review 
the facts.

I published an implementation *in an effort to clarify an 
existing spec* - implementing the YAIDIP as written by John 
Colvin and Andrei Alexandrescu, which is an evolution of DIP1027 
- on October 19th. https://github.com/dlang/dmd/pull/15714

In the process of working with that implementation, I found flaws 
in the design (in particular, it was incapable of handling tuple 
arguments, which includes nested strings, because they threw off 
the odd-even rule specified) and fixed them in a separate branch 
on October 20th (note that there are other potential ways to fix 
this issue, but since this was already a solution we debated and 
found working during the original dip1036 review, I stuck with it 
- that's why the PR is called "1036e", since it built on those 
existing principles). https://github.com/dlang/dmd/pull/15715

Note that DIP1036 was written primarily between September 2020 
and March 2021. This is not a new topic, many of us have spent a 
significant amount of time on the topic over a period of many 
years. 
https://github.com/dlang/DIPs/blob/344e00ee2d6683d61ee019d5ef6c1a0646570093/DIPs/DIP1036.md

There are, of course, several differences between the PR and the 
original dip1036 (whereas PR 15714 kept quite strictly to the 
YAIDIP's text), but we'll get to those soon.

So, remember, the code was written on October 20th.

To better show how the feature works in practice, I wrote the 
first of several user-facing examples on October 21st. 
https://github.com/adamdruppe/interpolation-examples/commit/ca4441508c9726519e769184cc7314fc0bf146b7

On October 23rd, Walter stated that the PR "Lacks 1: complete and 
accurate specification, or even a description. 2: comments. 3: 
test cases". 
https://github.com/dlang/dmd/pull/15715#pullrequestreview-1693080343

(Frankly, I think that very request is obnoxious, because on 
October 22nd, Walter posted his dip1027 implementation. I've said 
before that him doing this is a real slap in the face of the 
whole DIP process - his DIP was reviewed and rejected. He's been 
beating that dead horse for many, many years, never 
incorporating... or even *acknowledging* the feedback from 
reviewers. You probably recall my listing the receipts for this 
on New Year's Eve.

But nevertheless, compare the first draft of PR 15722 with the 
first draft of PR 15715. They're very similar, down to the 
semantic function both using the same `new MixinExp` hack (well, 
I thought it was a hack, until I saw Walter did it the same way, 
so apparently he thought it was a decent way to do it!). So I 
found it difficult to believe he was simultaneously capable of 
writing one implementation and incapable of understanding an 
independent, yet *very similar* implementation. Even if there 
were questions, he surely has significant foundation to ask them 
specifically and engage in a productive dialog. But instead, it 
was a vague drop and run. This is why there's an "us vs them" 
mentality - Walter acts not like a partner for peace, but rather 
as an obstacle to overcome. The DIP process structurally 
reinforces this - he is like the final boss to defeat after a 
grueling gauntlet to get to the prize.)

However, despite my skepticism, on October 24th, I started 
fulfilling that request, adding the first tests, which also 
double as basic documentation and examples on the compiler side, 
showing some specific edge cases that differentiate it from the 
original dip1036 text. 
https://github.com/dlang/dmd/commit/75f6f326695b5354c9ffb38ed4ec47b057881549

Additionally, on October 24th, I edited the first comment on the 
PR to incorporate a plain text description (similar in style to 
Walter's 1027 PR's introduction). (Click the "edited" drop down 
on the comment on Github to see the history with dates attached. 
Note that at the time Walter made the request, the plain text 
description was indeed not there. But shortly after he requested 
it, I edited it in to be easy to find.)

I added additional documentation, both comments on the 
implementation, more tests for specific edge cases that needed 
clarification, and VERY IMPORTANTLY a full user-facing 
documentation page on *October 26th*. 
https://github.com/dlang/dmd/commit/2ff8e2d1598d4b2cd581320095f526c8547c2c46#diff-22dd3c85816b0aa6351d1bc21e72ed410b509f8f7c768db3dd974967751b37e1

I've posted this link several times, and never got an 
acknowledgement from any of you that it exists.

Click that. Check the date on it. Read the contents on it. This 
is NOT code one has to reverse engineer. This is a description, 
written up as a standard D documentation block, for users to 
understand how the feature works.

Again, THIS IS NOT ASKING SOMEONE TO REVERSE ENGINEER THE CODE 
nor is it true that I refused to write documentation. There ARE 
examples, tests, comments, and two plain text descriptions, one 
aimed at the code reviewer and one aimed at the end user.


Walter requested a description on Monday, October 23rd. I 
answered that request by *Thursday, October 26th*. The examples 
and documentation I wrote over those three days form a 
significant fraction of Atila's DIP text! 
<https://github.com/atilaneves/DIPs/blob/string-interpolation/Interpolation.md>
(This dip was mostly written between December 18th and present day.)

Then, when we were on the DLF call on November 10th, more than 
two weeks AFTER I had *already written the requested 
documentation*, Walter again demanded a nebulous "spec" instead 
of engaging with the work that was already done.

I'd say "you have no idea how angry this makes me", but you were 
on that call. You certainly have some idea of how angry it makes 
me.

Now, I confess, my kneejerk reaction on that call, the sudden 
outburst of anger, was not an ideal response. I'm ashamed of the 
angry outburst. It surprised even myself. I was otherwise 
prepared with the documentation and examples written, but I was 
evidently not emotionally prepared.

Nevertheless, can we please, PLEASE, finally acknowledge the 
*verifiable fact* that I did NOT refuse to write documentation, 
but rather quite the contrary, actually *did* write the requested 
documentation within 72 hours of receiving the request.

If you all have a specific problem with this, you never 
communicated what it is. Do you (plural you, not you 
specifically, Mike) just not know it exists? Do you find the 
formatting unacceptable? The content insufficient? If so, in what 
way?

I'm actually inclined to think it you all honestly don't even 
know it is there. This would be consistent with many other cases 
where leadership made a request, the request was fulfilled, then 
silence. There's little follow-up.

You might notice that on those DLF calls, I prepared ahead of 
time for each one, starting with follow up on old business, then 
introducing new business. I kept the notes from the previous 
meeting and checked the links ahead of time so I could see what 
was done and what still needed to be done.

I suggest you do the same. But not just with meetings. Do it with 
any time - when you request something, put a note on your 
calendar to follow up on it some time later. In fact, it is best 
to communicate your schedule to the person you're requesting, 
such as "This needs documentation and test. I will check back in 
on Friday."

That's actually one useful bit of deadlines: they're a good time 
to schedule the follow up. Look back at the original request and 
see if it was done. E.g., reload the pull request page and glance 
it over for new pushes, then you can talk to the person you 
requested the work out of, knowledgeable of what was done to keep 
the conversation on topic and productive.

IIRC this was the key feature of the DIP redesign back when 
Dicebot proposed it - the old dips, before dip1000, were often 
left in limbo. The new process, with you taking up the role as 
dip manager, included various steps and timeframes to ensure 
something happened.

The new DIP process has also failed - i think the us-vs-them 
structure, frontloading the grinding work just to have it 
dismissed or misunderstood in an adversarial battle instead of 
refined in a cooperative, iterative process is the key to why - 
but ensuring you do get an answer in a predictable timetable is a 
good idea.


Anyway, I'm going back off this forum too. I have better things 
to do than argue in circles again as well.

Don Allen <donaldcallen gmail.com> writes:

On Friday, 19 January 2024 at 00:20:36 UTC, Adam D Ruppe wrote:
 I unsubscribed from this forum, since I find it to make me 
 angry and not lead anywhere productive, but people linked me to 
 this so I'll give one more reply to set the record straight.

 There's a ST:TNG scene that comes to mind relating to all this:

 https://www.youtube.com/watch?v=Owyj_5TuHQw

 "It's not you I hate, Cardassian. I hate what I became because 
 of you."

You are excusing the inexcusable, blaming it on someone else. 
Yes, I'm sure you endured months, years of frustration, which 
you've documented. You had options to address that problem, one 
of which you recently exercised. Behaving like a child who 
couldn't get his way was not one of them, at least one that 
reflects well upon you.

aberba <karabutaworld gmail.com> writes:

On Thursday, 18 January 2024 at 15:03:09 UTC, H. S. Teoh wrote:
 On Thu, Jan 18, 2024 at 02:02:56PM +0000, Dibyendu Majumdar via 
 Digitalmars-d wrote: [...]
 It only proves my point, because the only people not nice on 
 these forums are these so called contributors, many of who 
 actually have made no contribution but are happy to make a lot 
 of demands as if its their right!

 That's irrelevant.  Some of the people who left recently were 
 *very* active contributors, who have had a lot of work merged 
 and who did a lot of user support on their own free time.  
 We're not talking here about the regular whiners who show up 
 out of nowhere with strange or unreasonable demands ...

while not
 lifting a finger themselves. (Personally I just hit the delete 
 button for those, it's not worth my time.)

how do you know even those folks aren't contributors financially 
and other means? Would be a mistake to assess complaints based on 
such credentials.

Walter has a saying that people complain because they have 
interest in the language and care about it. I think that's a very 
positive way to look at it.

"H. S. Teoh" <hsteoh qfbox.info> writes:

On Fri, Jan 19, 2024 at 12:17:13AM +0000, aberba via Digitalmars-d wrote:
 On Thursday, 18 January 2024 at 15:03:09 UTC, H. S. Teoh wrote:
 On Thu, Jan 18, 2024 at 02:02:56PM +0000, Dibyendu Majumdar via
 Digitalmars-d wrote: [...]
 It only proves my point, because the only people not nice on these
 forums are these so called contributors, many of who actually have
 made no contribution but are happy to make a lot of demands as if
 its their right!

 
 That's irrelevant.  Some of the people who left recently were *very*
 active contributors, who have had a lot of work merged and who did a
 lot of user support on their own free time.  We're not talking here
 about the regular whiners who show up out of nowhere with strange or
 unreasonable demands ...  while not lifting a finger themselves.
 (Personally I just hit the delete button for those, it's not worth
 my time.)

 
 how do you know even those folks aren't contributors financially and
 other means? Would be a mistake to assess complaints based on such
 credentials.

I said specifically I was *not* talking about them. :-D

The "regular whiners" I was referring to are those who show up out of
nowhere and start asking "does D have X, Y, Z?" and then proceed to
whine "why is X like this? It should be more like X2!  And Y should be
more like Y2! And Z shouldn't even exist!  D sux, fix it or I'm
leaving!"


 Walter has a saying that people complain because they have interest in
 the language and care about it. I think that's a very positive way to
 look at it.

Well, that's why I'm still here and complaining. :-D  Or at least, I try
to post positive things about D when I can... but sometimes when you've
been around for a long time and seen things, it's hard not to voice
problems that you feel should have been obvious to everyone but for some
reason aren't. (Or so it appears.)


T

-- 
The best compiler is between your ears. -- Michael Abrash

zjh <fqbqrr 163.com> writes:

On Friday, 19 January 2024 at 00:29:44 UTC, H. S. Teoh wrote:

 Well, that's why I'm still here and complaining.


D's `feedback` is too slow. They are fixated on `details` but not 
on `contributors`. Everyone has left, how does your `D language` 
develop?

The most important aspect of D language is `ecology`, as a 
contributor rather than specific details. Specific details are 
indeed important, but compared to `contributors`, they are really 
not important.

claptrap <clap trap.com> writes:

On Thursday, 18 January 2024 at 14:02:56 UTC, Dibyendu Majumdar 
wrote:
 On Thursday, 18 January 2024 at 13:04:09 UTC, claptrap wrote:
 On Thursday, 18 January 2024 at 11:37:51 UTC, Dibyendu 
 Majumdar wrote:
 On Thursday, 18 January 2024 at 11:07:36 UTC, DrDread wrote:

 In a project like this, everything happens because someone 
 likes what you did, and wants to help, there is no obligation 
 for anyone to engage with anyone.

 I have no obligation to be nice to my freinds.

 But if I'm not I will quickly end up with none.

 See how that works?

 It only proves my point, because the only people not nice on 
 these forums are these so called contributors, many of who 
 actually have made no contribution but are happy to make a lot 
 of demands as if its their right!

LOL you aint proved nothing. You cant because you dont know who 
anyone is. You dont know who I am or what I contribute. You are 
just making assumptions and unfounded accusations because you 
cant argue with what I actually said.

You say nobody has any obligation to engage with anyone. You are 
100% right, it is so right it is pointless to say. But if you 
want people to help, you want to build a community, draw people 
to your cause then you absolutely have to engage with them. To 
expect one without the other would be utter stupidity.

M.M. <matus email.cz> writes:

On Thursday, 18 January 2024 at 11:07:36 UTC, DrDread wrote:
 On Thursday, 18 January 2024 at 11:02:29 UTC, Mike Parker wrote:
 On Thursday, 18 January 2024 at 10:54:44 UTC, DrDread wrote:
 On Wednesday, 17 January 2024 at 10:58:44 UTC, Dibyendu

 It is the contributors job to convince not the other way 
 round.

 see, there's your problem. it's not the contributors job, 
 they do this in their free time.
 if you want contributions you simply cannot act like that.

 Wrong. Spending your free time on a contribution does not 
 automagically make it correct, suitable, or worth having. 
 Every contribution has to be judged on its merits, not whether 
 or not it was done on a salaried or volunteer basis.

 The question should never be, "Why not merge this?" but always 
 "Why merge this?".

 you are still missing the point. it's not about rejecting a 
 proposal, it's about how the contributors are treated. how the 
 'management' wastes the time of contributors by not engaging 
 early.

Let's hold on. There is this general critique of how DLF manages 
and treats contributors (which DLF acknowledges and wants to work 
on improvements) and there is this explicit statement/discussion:

* person_1: "It is the contributor's job to convince the language 
maintainers of adding a particular contribution."
* your reply (paraphrasing): No, it is not contributors' job, 
because they do it in their free time."
* Mike (paraphrasing): "Wrong. Spending free time does not 
warrant a correct and worth-having contribution. Every 
contribution has to be judged on its merits."
* your reply (paraphrasing): "You are missing the point. It is 
not about rejecting a proposal. It is about how contributors are 
treated."

Now, where in the discussion above was the point of "how 
contributors are treated" raised that you want to correct a view 
on this? As I see it, the whole discussion is about "contributors 
need to convince the language maintainers about the quality and 
merit of contributions", and not about "what is the interpersonal 
interaction in the process of convincing the language 
maintainers".

cc <cc nevernet.com> writes:

On Tuesday, 16 January 2024 at 20:38:37 UTC, Walter Bright wrote:
 https://github.com/dlang/dmd/pull/15715

 I was unconvincing in my arguments, there was too much 
 acrimony, and its effects do not affect the rest of the 
 language. The only credit I can take is my constant challenges 
 to it caused it to evolve into a much better proposal.

 Steven has graciously volunteered to work on the addition to 
 the language spec, thank you!

Looking forward to this, thanks to all involved.