I’ve been told by randoms a couple of times now that some proposed change, which I considered a minor enhancement, needs a DIP. How do people determine that? What are the “official” rules on what needs a DIP and what doesn’t? As far as I see, there aren’t any.

My sense was that, informally:

• Any change that necessitates potentially real-world breakage needs a DIP.
• Mere additions need a DIP if they introduce a new language feature.
• Even small additions need a DIP if they require justification in terms of cost–benefit ratio, with cost both in terms of initial implementation and long-term maintenance.

What doesn’t fit those criteria, are additions that give The Obvious Meaning™ to something that is currently an error and has obvious benefits for little implementation cost and essentially no additional maintenance cost.

On Friday, 5 May 2023 at 14:28:38 UTC, Quirin Schroll wrote:

I believe these are the official rules:

https://github.com/dlang/DIPs/blob/master/docs/process-authoring.md#when-to-write-a-dip

On Friday, 5 May 2023 at 14:28:38 UTC, Quirin Schroll wrote:

Dip can increase the success rate of submissions with destructive changes.
Moreover, writing 'dip' can increase your weight in 'DLF'.
I think it's best to create a 'dip' for any improvement with 'characteristics', which is convenient for reading and can be used as a key reference for 'documents'. Of course, it's best to simplify the 'dip' process appropriately.

On 5/5/23 10:28 AM, Quirin Schroll wrote:

Not necessarily. If this is a bug fix, then it may not need a DIP. Especially if a deprecation can help people migrate their code.

"language feature" is pretty broad. If, for example, you want to add a new property/function that can be used on an associative array, then it might be OK to add without a DIP. But these are judgment calls that probably need someone higher up to make.

Yeah.... Again, judgment calls from others can help.

What I'd recommend is to propose the change here, see what people say, and then if it's agreed that a DIP is required, start the process. Writing and successfully navigating a DIP through the process isn't trivial, and it sucks to do it and have someone say it wasn't necessary, or that it had no chance of succeeding.

-Steve

On Friday, 5 May 2023 at 15:10:12 UTC, Steven Schveighoffer wrote:

Fixing a bug that people relied on being there is a separate discussion.

Wouldn’t that be a library feature? I mean, sure, associative arrays are specified by the language, but from a programmer perspective, they could as well be in Phobos.

By language feature I meant core functionality that the language offers. An example would be HTML entities in string literals. D supports them, but if it didn’t, suggesting them would constitute a (core) language feature.

Allowing attributes on unit tests after the unittest keyword does not add any functionality, it’s not a (core) language feature. (And IMO wouldn’t require a DIP.)

I did: https://forum.dlang.org/thread/lxcjsxxamwwtkdpmjhze@forum.dlang.org

In my opinion, it does not require a DIP. It’s basically like the unittest example.