Hi,

Dave Thomas wrote:
> What would happen if we added no options, waited to see what issues were 
> raised by users, and then addressed those? Adding features preemptively 
> seems like it could add bloat to the language that future generations of 
> maintainers will have to support, even if users don't need them.

Even if no options, all functions which those options will help are 
already available.  Those options are for performance and usability. 
They are hard to clear.

e.g. String#gsub(regexp, hash) is for performance and usability

Off cource too many options is evil, that's true.

> I have to say that I'd also like to see a little more emphasis on 
> stability issues and core bugs at this stage. Let's get something stable 
> out, so that real users can play. We can then add features based on 
> their reported needs.

I don't think so.  You say, developing software is categolized some stages:
1. implement stage
2. stability stage
3. extend stage
And now stability oriented stage.

I say no, String#encode is still implement stage.  Before 1.9.0 we 
discussed about functions of String#encode and some of them are still 
not implemented, for example error fallbacks, right CP932 support, right 
statefull encoding support, C API for Ruby extensions and so on.

-- 
NARUSE, Yui  <naruse / airemix.com>
DBDB A476 FDBD 9450 02CD 0EFC BCE3 C388 472E C1EA