Formal review of std.lexer

[Meta]

On Monday, 24 February 2014 at 23:07:07 UTC, Adam Wilson wrote:
> Well, we keep voting down replacement candidates, which 
> incidentally, is exactly what happened with the std.signals 
> replacement, so I view this as an orthogonal issue to whether 
> or not it should be included after passing a review. I don't 
> think the fact that a module might not be perfect after review 
> should stop us from approving a module that offers completely 
> new functionality AND passed a review. Handling the problems 
> after inclusion is what bugzilla is for.

I guess std.signals was a bad example, as there *was* a proposed 
replacement. However, there were real problems with the 
replacement that made it not suitable for inclusion. If I recall, 
these were largely API issues, which are the hardest to change. 
If we had've accepted the new std.signals despite the issues 
raised, several years down the road it might turn out to be as 
broken as the old implementation (no offense to the author, this 
is just for the sake of argument), and we are unable to replace 
it for fear of breaking code. There are then 2 options: support 
the old API with its broken behaviour in the same module as the 
new API, or introduce std.signals2 or the like, which people have 
shown resistance to in the past. I think that it's very important 
to be careful as to what goes into Phobos at this point, as it's 
going to become increasingly difficult to change anything.