Re: Incubated modules for Phobos

[Marco Leise]

The idea reminds me of how extensions are managed in OpenGL:  
http://www.opengl.org/resources/features/OGLextensions/
Often hardware vendors like S3, nVidia or ATi invented cool stuff, like  
texture compression and were free to add a prefixed function name to their  
drivers (S3_…, NV_…, ATI_…). Sometimes other vendors would implement those  
functions as well and they are eventually renamed to EXT_…. Then there is  
the architecture review board (ARB) that picks up these extensions and  
evaluates how they could fit into OpenGL. Often changes are necessary for  
the function to become ARB_…. I think this is all still independent of the  
specification release cycle (OpenGL is just a specification). When a new  
specification is planned, ARB_… functions make it into GL_… core  
functionality.
I believe this concept helps innovation. But who would decide which module  
is a good fit for Phobos and which one is better fetched through an  
external package manager? For example, what if I came up a complete  
containers package that has different approaches from std.containers or a  
2D drawing/image API or a D compiler front-end?
In OpenGL terminology, I think it would be an ARB_… already, if it is in a  
distribution of DMD. It would have a specification that some review board  
has accepted for inclusion into Phobos. Anything with a clear  
specification on paper or as an implementation could be accepted, but on  
the other hand, just saying that "I start writing an image handling  
module" should not be enough to be in .ext in Phobos. Otherwise some .ext  
modules will disappear suddenly or get stuck there forever, because as  
they mature the review board realizes, that the API is not going to be  
what they like to see in Phobos. That's frustrating for both the developer  
and users.

So in short: yes, but review what ends up in .ext