D Enhancment proposals

[Andrei Alexandrescu (See Website For Email)]

Kirk McDonald wrote:
> Bill Baxter wrote:
>> Andrei Alexandrescu (See Website For Email) wrote:
>>
>>> Bill Baxter wrote:
>>>
>>>> Derek Parnell wrote:
>>>>
>>>>> On Mon, 19 Mar 2007 15:05:29 -0700, Andrei Alexandrescu (See 
>>>>> Website For
>>>>> Email) wrote:
>>>>>
>>>>>
>>>>> I wish it wasn't so hard to get a simple straight answer from the 
>>>>> experts.
>>>>
>>>>
>>>> I think discussion would much improved if big changes like this 
>>>> actually came with a detailed proposal on a website somewhere that 
>>>> people could refer to and which would actually be updated to reflect 
>>>> vague points clarified during discussion.  As it is, there are a lot 
>>>> of points that have been clarified, and questions answered, but 
>>>> they're strewn across 100 different posts.  I'm pretty lost.  I gave 
>>>> up trying to follow this myself.  I'm hoping you'll figure it out 
>>>> and post something coherent. :-)
>>>>
>>>> On the bright side, thanks to Andrei, at least there *is* an open 
>>>> discussion going on about the feature before it just shows up in the 
>>>> change log as a done deal.
>>>
>>>
>>> I agree. (How couldn't I? Flattery goes a long way :o).)
>>>
>>> Maybe we could imitate what other languages do, e.g. Perl has the 
>>> famous "apocalypses" that describe each language feature in detail.
>>
>>
>> I was thinking more of Python's PEPs, but yeh, same deal.  I like PEPs 
>> in that anyone can submit one, get it assigned an offical number.   As 
>> opposed to Larry's stone tablets brought down from the mountain top 
>> for the rest of us to ooh and ahh over.  Python's way is a little more 
>> egalitarian.
>>
>> Semi-official Enhancement Proposals are also a good way to handle the 
>> many repeated requests for 'feature X'.   Just tell 'em -- great idea, 
>> now go write a DEP for it.  If they actually do it, then great.  Next 
>> time someone asks for the feature you just point 'em to the previous 
>> DEP and the BFD ruling on it.
>>
>> My impression is that PEPs get weighted somehow based on how 
>> fleshed-out they are.  For instance it seems a majority of PEPs (at 
>> least the ones I've read) come complete with prototype 
>> implementations.  So PEP is more than just a vague wish like "Please 
>> implement Java-style serialization".  It has to contain the nitty 
>> gritty details.
>>
>> --bb
> 
> The PEP numbers are also a convenient way to refer to certain issues or 
> features: "Oh the 'with' statement? That's PEP 343." The PEP can also 
> serve as a starting point for the official documentation of the feature.
> 
> Most importantly, they serve as a fixed locus of discussion, and can 
> vastly improve the low signal-to-noise ratio that running around in 
> circles on a mailing list or newsgroup can cause.
> 
> In other words:
> DEPs++

I, too, think that's a great idea.

Andrei