In relation to this post: http://forum.dlang.org/thread/ssiulznvtkmfkimmatpk@forum.dlang.org?page=5#post-knnghuzbzqddaqcjtvch:40forum.dlang.org
I hereby open up again the discussion about auto ref.
There are only some questions: Will auto ref be implemented in the near future or not? If not, with which version it will probably come?
Or is auto ref forgotten and we have to discuss about the need and the syntax again?
There is still a pull from Kenji (#1019) which is waiting for completion and merging (thanks for that, Kenji).
But it seems that this whole topic isn't that important (or am I wrong?), but the need for such feature is still there, exceedingly since with dmd 2.061 structs aren't lvalues anymore. We need const& for D. Without that, massive struct usage is very unhandy.
I hope for an official statement from Walter and/or Andrei. Let the games begin.

And in advance: I'm from Germany, so English is not my native language. So forgive my bad English.

On 1/26/13 6:03 AM, Namespace wrote:
> In relation to this post:
> http://forum.dlang.org/thread/ssiulznvtkmfkimmatpk@forum.dlang.org?page=5#post-knnghuzbzqddaqcjtvch:40forum.dlang.org
>
> I hereby open up again the discussion about auto ref.
> There are only some questions: Will auto ref be implemented in the near
> future or not?

Yes. We are actively looking into a complete solution. Along the way we also very strongly want to define semantics of "ref" in such a way that makes unsafe escapes impossible. These two features are related.

Andrei

> Yes. We are actively looking into a complete solution. Along the way we also very strongly want to define semantics of "ref" in such a way that makes unsafe escapes impossible. These two features are related.
>
> Andrei

That's good to know. But can you estimate _when_ it will be implemented or with which version? That would be very informative.

On Saturday, 26 January 2013 at 16:27:04 UTC, Andrei Alexandrescu wrote:
> On 1/26/13 6:03 AM, Namespace wrote:
>> In relation to this post:
>> http://forum.dlang.org/thread/ssiulznvtkmfkimmatpk@forum.dlang.org?page=5#post-knnghuzbzqddaqcjtvch:40forum.dlang.org
>>
>> I hereby open up again the discussion about auto ref.
>> There are only some questions: Will auto ref be implemented in the near
>> future or not?
>
> Yes. We are actively looking into a complete solution. Along the way we also very strongly want to define semantics of "ref" in such a way that makes unsafe escapes impossible. These two features are related.
>

Wouldn't it be nice if such thing would be settled BEFORE breaking quite a lot of code when changing this behavior in 2.061 ?

On Saturday, 26 January 2013 at 17:02:40 UTC, deadalnix wrote:
> On Saturday, 26 January 2013 at 16:27:04 UTC, Andrei Alexandrescu wrote:
>> On 1/26/13 6:03 AM, Namespace wrote:
>>> In relation to this post:
>>> http://forum.dlang.org/thread/ssiulznvtkmfkimmatpk@forum.dlang.org?page=5#post-knnghuzbzqddaqcjtvch:40forum.dlang.org
>>>
>>> I hereby open up again the discussion about auto ref.
>>> There are only some questions: Will auto ref be implemented in the near
>>> future or not?
>>
>> Yes. We are actively looking into a complete solution. Along the way we also very strongly want to define semantics of "ref" in such a way that makes unsafe escapes impossible. These two features are related.
>>
>
> Wouldn't it be nice if such thing would be settled BEFORE breaking quite a lot of code when changing this behavior in 2.061 ?

Absolute agreement.
While it is true that structs are not lvalues​​, but to fix this known bug, without implement a solution for rvalue references was a really bad idea.
This bug was so long tolerated because we hadn't a solution for rvalue references. So it would be good to know, why it was fixed this time, although we have still no rvalue refs.

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

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.

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

> 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.
No, as far as I can see this don't happend. auto ref works currently very well for template functions and the pull I suggest adds the same functionality for normal functions.
So if one day an official solution is there, nothing will be broken. The solutions code has (maybe) another implementation but it don't touch auto ref functionality in general.
>
> 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.
Yes, in my opinion this feature is a very important and basic thing that every language should have.

> 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

Good to hear that I'm not alone with this.

On Sunday, January 27, 2013 01:32:07 Namespace wrote:
> > 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.
> 
> No, as far as I can see this don't happend. auto ref works
> currently very well for template functions and the pull I suggest
> adds the same functionality for normal functions.
> So if one day an official solution is there, nothing will be
> broken. The solutions code has (maybe) another implementation but
> it don't touch auto ref functionality in general.

But it may not even end up being the case that using auto ref on non-templated functions is the solution. It may end up being something else entirely. Ignoring @safety issues, it seems to me like it would be the most straightforward solution, but there are @safety issues with ref in general that need to be addressed, and Andrei intends to address them as part of whatever happens with auto ref. That mean that auto ref gets used for non- templated functions, or it could mean something very different. I don't know what exactly the solution that Andrei is working on could entail. For all I know, it'll involve letting ref in general accept rvalues (much as I tihnk that that's a horrible idea, it _has_ been suggested before). So, without a clear idea of what we're going to want to do, merging in the pull request which makes auto ref work for non-templated functions is a bad idea. It could ultimately end up being fine, or it could end up breaking more code when the real solution gets implemented.

- Jonathan M Davis