www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - What requires a DIP?

reply Quirin Schroll <qs.il.paperinik gmail.com> writes:
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.
May 05 2023
next sibling parent bachmeier <no spam.net> writes:
On Friday, 5 May 2023 at 14:28:38 UTC, Quirin Schroll wrote:

 What are the “official” rules on what needs a DIP and what 
 doesn’t?


I believe these are the official rules:

https://github.com/dlang/DIPs/blob/master/docs/process-authoring.md#when-to-write-a-dip
May 05 2023
prev sibling next sibling parent zjh <fqbqrr 163.com> writes:
On Friday, 5 May 2023 at 14:28:38 UTC, Quirin Schroll wrote:

 I’ve been told by randoms a couple of times now that some 
 proposed change, which I considered a minor enhancement, needs 
 a DIP.



`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.
May 05 2023
prev sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 5/5/23 10:28 AM, Quirin Schroll wrote:


 My sense was that, informally:
 * Any change that necessitates potentially real-world breakage needs a DIP.


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.


 * Mere additions need a DIP if they introduce a new language feature.


"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.


 * 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.


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
May 05 2023
parent Quirin Schroll <qs.il.paperinik gmail.com> writes:
On Friday, 5 May 2023 at 15:10:12 UTC, Steven Schveighoffer wrote:

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


 My sense was that, informally:
 * Any change that necessitates potentially real-world breakage 
 needs a DIP.


 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.


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


 * Mere additions need a DIP if they introduce a new language 
 feature.


 "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.


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.)


 But these are judgment calls that probably need someone higher 
 up to make.


 * 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.


 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.


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.
May 06 2023