View mode: basic / threaded / horizontal-split · Log in · Help
January 26, 2013
auto ref - again
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.
January 26, 2013
Re: auto ref - again
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
January 26, 2013
Re: auto ref - again
> 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.
January 26, 2013
Re: auto ref - again
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 
?
January 26, 2013
Re: auto ref - again
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.
January 26, 2013
Re: auto ref - again
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
January 26, 2013
Re: auto ref - again
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.
January 26, 2013
Re: auto ref - again
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
January 27, 2013
Re: auto ref - again
> 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.
January 27, 2013
Re: auto ref - again
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
« First   ‹ Prev
1 2 3 4
Top | Discussion index | About this forum | D home