auto ref - again

[Jonathan M Davis]

On Saturday, January 26, 2013 20:25:15 Namespace wrote:
> On Saturday, 26 January 2013 at 19:08:20 UTC, Jonathan M Davis
> 
> wrote:
> > On Saturday, January 26, 2013 17:51:23 Namespace wrote:
> >> That's good to know. But can you estimate _when_ it will be
> >> implemented or with which version? That would be very
> >> informative.
> > 
> > Things generally just don't work that way around here. They get
> > done when they
> > get done. And often some of the more important stuff takes a
> > while, because it
> > takes a while to get the design sorted out and implemented
> > (especially if
> > Walter is the one to implement it). So, much as it might be
> > nice to have a
> > roadmap saying when something is expected to be done, that
> > pretty much never
> > happens.
> > 
> > - Jonathan M Davis
> 
> And why? For special cases like this it could be helpfull and it
> is IMO possible.
> You have the pull and know what's went wrong with it (it breaks
> unittests). So you could say, how long it takes, until it is
> ready to merge.
> 
> Another proposal, that I've suggested in another thread, would be
> to merge some "placeholder" pull which fix the problem until the
> official solution is implemented. I thought about this pull:
> https://github.com/D-Programming-Language/dmd/pull/1428
> It is ready for merging and usage. This pull adds functionality
> for non-template auto refs but it doesn't change the (template)
> auto ref functionality in general, as Kenjis pull does.

If we add a feature as a temporary measure and then remove it later, we're 
likely to end up breaking code when it's removed. It's not clear what the 
ultimate solution is going to be, particularly since Andrei is looking to fix 
refs in general (and based on previous discussions on this, I believe that 
Walter is looking to do the same), the solution could be more complicated. I 
don't know what they're going to do with it. But I'd be very surprised if 
anything were merged in to solve the problem before they've decided what they 
want to do.

You seem to be in a big hurry to have this problem solved, but very little 
moves at that kind of pace around here, even if it's very important. If it 
were simply a bug fix, then someone (including you) could hop in, sort it out, 
and submit a fix, and it might get merged in fairly quickly (though the rate at 
which even straightforward pull requests gets merged in varies considerably). 
But this isn't just a bug fix. It affects the fundamental design of a portion of 
the language, which means that a design needs to be presented that satisfies 
both Walter and Andrei. Changes like that just don't happen quickly. And 
Andrei and Walter have some very definitive ideas about what they want to be 
able to guarantee with ref and @safe, and doing that isn't easy. I don't 
expect that any solution to this will be merged in until they've agreed upon a 
solution. And I have no idea how long that will take. It sounds like Andrei is 
treating it as a relatively high priority for himself to sort out the problem, 
but he's a very busy fellow, and pretty much anything that requires a lot of 
work on his part tends to take a while as a result.

So, while I can understand your frustration (and on some level share it), on 
an issue like this, you're just going to have to be patient. Making a big deal 
about it may get it to happen faster by bringing more attention to it, but 
it's still not going to be as simple as just merging a pull request, not with 
an issue like this.

- Jonathan M Davis