On 12/21/2023 6:35 AM, Guillaume Piolat wrote:
> My point is that we spend so much time using and translating C libraries because they have desirable characteristics that the STL-style D (and C++) libraries lacks.

I understand. I also know that C libraries are always going to be a couple of order of magnitudes more plentiful.

On Friday, 22 December 2023 at 00:02:01 UTC, Walter Bright wrote:
> Every organized and professional product I know of requires a specification to come with every formal proposal for a language change.

Not the case with ImportC apparently, when you can just show up, make a 5K LOC PR out of thin air, mark it "trivial" and have 0 spec or rationale prepared. Good double standards bro.

> They're not that much work, they're certainly a lot easier than an implementation.

Don't you just go around assuming what is easy for people and what isn't. And it's not even a question of being easy, it's a question of wasting time on something that you would just veto anyway, so why bother?

> It is normal for organized language communities to require a spec for any language changes. I'm not aware of any that don't.

Here is an example of such language: D. Because, apparently, spec is only requried when you personally feel like it, otherwise it's whatever goes.

On Thursday, 21 December 2023 at 15:19:27 UTC, Adam D Ruppe wrote:
> Phobos had a big inrush of development many years ago, but since then it has been a trickle, leaving wide gaps in functionality and questionable design that everyone agrees should be changed, yet it remains entrenched. Sure, some nice things are added, some bugs fixed, but they are few and far between. Is this because of a lack of people power? No! There's lots of people willing, some even *eager* to contribute to Phobos, but they are instead turned away

I pulled some historical information today. The phobos rush of development around 2010 was the outlier; the rest of its life has been similar - slow and virtually closed.

You might have heard of the old stdlib wars; Tango vs Phobos. Care to guess how this started? 2004 - D was very young - and substantial parts of the community felt that Phobos "wasn't moving in any direction, useful features were missing and no one could easily provide code (or didn't feel as though they could)"[1] (this quote was written in November 2008, exact author unknown), so Sean Kelly, et.al., created a project later called "Ares" with a key goal of "produc[ing] a fully functional standard library for D" with a very important note that differentiated it from Phobos: "The Ares project will gladly accept all submissions for review and/or inclusion. Contributors are encouraged to respond to any community feedback and re-submit any changes or improvements they deem appropriate." [2] (that summary written in Sept 2005)

As one contemporaneous account summarized working with upstream: "Walter blesses many ideas. What I'm wondering is how quickly he incorporates the results." and citing, as a downside of an upstart competitor (which btw ive never heard of until now): "and it's still dependent on Walter, as it usually is." [3] (Sept 2004)

In 2006, a new user asked about the library situation. The answer: "Ares is also likely to be the staging point for other low-level enhancements by the community; last I checked, Sean was faster at responding to library contributions than Walter." [4]

It is worth noting that in Oct 2008, after being eviscerated in the press over having "two standard libraries", upstream FINALLY relented and merged parts of Ares (then known better as a major component of the Tango library) upstream as "druntime" in 2.020. [5]

But, despite some positive changes and some exciting periods of development, many of those 18 year old posts could just as well be posted today.

1: http://www.prowiki.org/wiki4d/wiki.cgi?StandardLib
2: http://www.dsource.org/forums/viewtopic.php?t=990
3: http://www.dsource.org/forums/viewtopic.php?t=342
4: http://www.dsource.org/forums/viewtopic.php?t=1873
5: http://www.dsource.org/forums/viewtopic.php?t=4229

On Friday, 22 December 2023 at 00:19:36 UTC, Walter Bright wrote:
> On 12/21/2023 9:14 AM, aberba wrote:
>> Is a spec required when submitting a feature?
>
> Yes, unless it is trivial.

>
>> Looks like it a lot of work.
>
> They're not that much work, they're certainly a lot easier than an implementation.

Wouldn't it be easier if there's at least an interest shown towards such efforts? It looks to me that the implementation is good (considering Atila is looking to write the Spec in the format you consider appropriate). So now, with an implementation and docs already done, it could be reassuring if the authors are made to know if you're willing to include the implementation or not considering it's a lot of work implementing the feature and writing a spec only to find out it's not going to be included at all. D is a small community so I feel it makes sense that the process is adjusted a bit to be more "human".


>
>> Must it be done initially even when the implementation will likely be rejected?
>
> It is normal for organized language communities to require a spec for any language changes. I'm not aware of any that don't.

Hmm. I understand your point. But that's when the change is DEFINITELY going to be included, right?

But until then, are you able to comment whether you're happy with the current implementation or not?

I think a small community like D should be able to facilitate such a process. We shouldn't have a bureaucracy problem at this stage. Could be demoralizing.

On Friday, 22 December 2023 at 00:19:36 UTC, Walter Bright wrote:
> It is normal for organized language communities to require a spec for any language changes. I'm not aware of any that don't.

We do not have a committee, your are a dictator for life, formal documents are how committees communicate *among* themselves, we are often peasants before a king. I don't sit on a committee, I don't how a title, why should I try to be fancy? Im better off playing a jester to amase the king.

We should pretend to balance concerns trying to get a majority to vote on something, its ummmmm you and your aesthetic concerns for what will make news on hn or something.

If you wish to make a commmitty, I suggest you get a list of names of people with d projects, pick 30 by lottery, and give them the power to merge a patch *despite your objections* with a supermajority.

On Friday, 22 December 2023 at 20:54:02 UTC, aberba wrote:
> On Friday, 22 December 2023 at 00:19:36 UTC, Walter Bright wrote:
>> On 12/21/2023 9:14 AM, aberba wrote:
>>> Is a spec required when submitting a feature?
>>
>> Yes, unless it is trivial.
>
>>
>>> Looks like it a lot of work.
>>
>> They're not that much work, they're certainly a lot easier than an implementation.
>
> Wouldn't it be easier if there's at least an interest shown towards such efforts? It looks to me that the implementation is good (considering Atila is looking to write the Spec in the format you consider appropriate). So now, with an implementation and docs already done, it could be reassuring if the authors are made to know if you're willing to include the implementation or not considering it's a lot of work implementing the feature and writing a spec only to find out it's not going to be included at all. D is a small community so I feel it makes sense that the process is adjusted a bit to be more "human".
>

This isn't about the feature itself, but the implementation. We're going to get string interpolation. Walter has an implementation that he prefers. There's already been a good deal of discussion about Adam's implementation here in the forums. Adam brought it up in a monthly meeting. That's when Walter asked for a spec. He wants to be sure he understands it fully so that he can make a fair judgement.

To communicate a proposal to users, a specification is also needed. Telling users to read the code isn't going to work.

A specification is needed to determine what the proposal is, and what it is not. It is also used to judge whether the implementation is correct or not.

On 12/21/2023 4:38 PM, Adam D Ruppe wrote:
> Well, it defines how you define "spec".

It's a document that describes the complete and exact behavior of the language change.

From the spec alone one should be able to create a complete and conforming implementation of it.

Clarifying usage examples are often part of the spec. Tutorials are not part of the spec.

The text of the specification, once the proposal is adopted, will be merged with the language specification.

I don't expect it to be as formal as, say, the C Standard is. But it should be good enough that someone could implement it completely and correctly without needing to refer to an existing implementation.

On Saturday, 23 December 2023 at 06:18:16 UTC, Walter Bright wrote:
> To communicate a proposal to users, a specification is also needed. Telling users to read the code isn't going to work.

Dozens of other people have had no trouble reading the extensive documentation and numerous usage examples.

In fact, more often than not, telling users to read a specification doesn't work - documentation and examples tend to be much better teaching tools.

> A specification is needed to determine what the proposal is, and what it is not. It is also used to judge whether the implementation is correct or not.

For a new feature, there is no meaningful difference between a spec bug and an impl bug. The question at hand is if the behavior is *useful* or not.

On 12/22/2023 1:47 AM, GrimMaple wrote:
> Not the case with ImportC apparently, when you can just show up, make a 5K LOC PR out of thin air, mark it "trivial" and have 0 spec or rationale prepared. Good double standards bro.

ImportC was not a D language change. C has a standard, C11, which ImportC implements.