On Thursday, February 26, 2015 20:35:02 deadalnix via Digitalmars-d wrote: > On Thursday, 26 February 2015 at 11:10:16 UTC, Paolo Invernizzi > wrote: > > I think the real problem goes clearly beyond enums, it's an > > overall approach to changes in the D language itself. > > > > I join to deadalnix's worries. > > > > --- > > Paolo > > Yes, I don't care about the specific enum case, in fact, that is > one of the least offender and this is why I choose it as an > example here. > > What worries me is that whatever way you take the problem there > is a good reason not to proceed. And, taken independently, every > one of these reason are valid, or at least something reasonable > people can agree upon. > > But there is no way we can agree on all of these at once.
Well, I suspect that each case would have to be examined individually to decide upon the best action, but I think that what it comes down to is the same problem that we have with getting anything done around here - someone has to do it. For instance, we all agree that std.xml needs to be replaced with something range-based and fast rather than what we currently have, but no one has made the time or put forth the effort to create a replacement and get it through the review process. Someone has to step up and do it, or it'll never get done. With language changes, it's often the same. Someone needs to come up with a reasonable solution and then create a PR for it. They then have a much stronger position to argue from, and it may get in and settle the issue. And it may not get merged, because it still can't be agreed upon as the correct solution, but an actual implementation carries a lot more weight than an idea, and in most of these discussions, we just discuss ideas without actually getting the work done. If we want stuff like this to get done then more of us need to find the time and put forth the effort to actually do it and be willing to have put forth the time and effort only to have our work rejected. But many of us are very busy, and we've failed to attract enough new contributors on big stuff to get many big things done by folks who haven't been doing a lot already. We probably need to find a way to encourage folks to do bigger things than simply making small improvements to Phobos - be it writing a potential, new module for Phobos or be it implementing critical stuff in the compiler. - Jonathan M Davis
