April 17, 2013
On Wednesday, 17 April 2013 at 20:27:27 UTC, Namespace wrote:
> Oh, I thought you had anything against the DIP. ^^
> Yes that annoys me as well. That's why I really hope that we can fix this vexing issue soon. :)

Yes, this temp ref issue is far more important than the ref safety issue I've been concerning myself with. I wouldn't mind if the objections I've brought up fall in favor of whatever it takes to get temp ref solved. ref safety is important, but it's nowhere near the shear *annoyingness* factor of rvalue temp refs. But someone besides me would need to evaluate both DIP 35 & 36 to see if there were any real conflicts there.
April 20, 2013
> Yes, this temp ref issue is far more important than the ref safety issue I've been concerning myself with. I wouldn't mind if the objections I've brought up fall in favor of whatever it takes to get temp ref solved. ref safety is important, but it's nowhere near the shear *annoyingness* factor of rvalue temp refs.
That is true, but it makes the impression that, with the exception of Kenji, none of the core developers is interested in a solution to this problem.
The DIP was not much discussed and the pull request is regularly overlooked / ignored.
Also in the discussion on the pull request no comments for Walter or Andrei are found. Although the pull is complete and has passed all the tests and would be ready to merge.
Also this thread is completely ignored even though both write in this forum regularly and participate in other discussions.
To me this makes the impression that they were not interested in this problem (or in our solution to the problem). Either they want the problem does not solve or try to solve it in their own way and that can take a very long time.
At least an annotation what of both is the case or if I see it completely wrong, would be polite.

> But someone besides me would need to evaluate both DIP 35 & 36 to see if there were any real conflicts there.
Yes that would be good.
April 20, 2013
On Saturday, 20 April 2013 at 14:42:57 UTC, Namespace wrote:
>> Yes, this temp ref issue is far more important than the ref safety issue I've been concerning myself with. I wouldn't mind if the objections I've brought up fall in favor of whatever it takes to get temp ref solved. ref safety is important, but it's nowhere near the shear *annoyingness* factor of rvalue temp refs.
> That is true, but it makes the impression that, with the exception of Kenji, none of the core developers is interested in a solution to this problem.
> The DIP was not much discussed and the pull request is regularly overlooked / ignored.

I don't think adding more to the language is the sane thing to do right now.
April 20, 2013
> I don't think adding more to the language is the sane thing to do right now.

Why not? Could you explain this?
This issue is discussed since more than a year and it is a very annoying issue.
And even if Walter and Andrei are of this opinion, it would still only polite when they explain in detail why they think this.
April 20, 2013
On Saturday, 20 April 2013 at 15:17:39 UTC, Namespace wrote:
>> I don't think adding more to the language is the sane thing to do right now.
>
> Why not? Could you explain this?
> This issue is discussed since more than a year and it is a very annoying issue.
> And even if Walter and Andrei are of this opinion, it would still only polite when they explain in detail why they think this.

Listen, this issue is very real, but it is mostly about performance. I'll tell you something : the best performance improvement is the one that bring your program from non working state to working one. And right now, many existing feature are broken.

The let's add whatever feature we have in mind is the very cause of the state of the language right now.
April 20, 2013
> Listen, this issue is very real, but it is mostly about performance. I'll tell you something : the best performance improvement is the one that bring your program from non working state to working one. And right now, many existing feature are broken.
>
> The let's add whatever feature we have in mind is the very cause of the state of the language right now.

As far as I remember, you were in favor of the introduction of the feature "attribute inference for auto functions". Also a new feature but none that would solve problems which are discussed since more than a year.
Furthermore this issue should be solved with the introduction of "auto ref" (AFAIK introduced with dmd 2.035?). So this is not like "add whatever feature" but rather "fix an issue, that is often discussed and annoys many people".
April 20, 2013
On Saturday, 20 April 2013 at 15:23:35 UTC, deadalnix wrote:
> On Saturday, 20 April 2013 at 15:17:39 UTC, Namespace wrote:
>>> I don't think adding more to the language is the sane thing to do right now.
>>
>> Why not? Could you explain this?
>> This issue is discussed since more than a year and it is a very annoying issue.
>> And even if Walter and Andrei are of this opinion, it would still only polite when they explain in detail why they think this.
>
> Listen, this issue is very real, but it is mostly about performance. I'll tell you something : the best performance improvement is the one that bring your program from non working state to working one. And right now, many existing feature are broken.
>
> The let's add whatever feature we have in mind is the very cause of the state of the language right now.

Sadly, I have to agree on this. As nice as many new feature ideas are, they are far from priorities when there are multiple core mechanics that are broken.
April 20, 2013
On Saturday, 20 April 2013 at 15:39:42 UTC, Namespace wrote:
>> Listen, this issue is very real, but it is mostly about performance. I'll tell you something : the best performance improvement is the one that bring your program from non working state to working one. And right now, many existing feature are broken.
>>
>> The let's add whatever feature we have in mind is the very cause of the state of the language right now.
>
> As far as I remember, you were in favor of the introduction of the feature "attribute inference for auto functions". Also a new feature but none that would solve problems which are discussed since more than a year.

Half of the standard lib is broken because it is annotated incorrectly.

> Furthermore this issue should be solved with the introduction of "auto ref" (AFAIK introduced with dmd 2.035?). So this is not like "add whatever feature" but rather "fix an issue, that is often discussed and annoys many people".

DIP36 discuss the addition of new features.
April 20, 2013
You miss quite an important point - DIP36 does not add new feature. It partially defines existing feature (scope) to replace an existing but broken solution (auto ref). Nothing new is really added to the language, only existing stuff better defined.
April 20, 2013
> Sadly, I have to agree on this. As nice as many new feature ideas are, they are far from priorities when there are multiple core mechanics that are broken.

There is no reason to prioritize DIP 36. Kenji, Dicebot and I did most of the work. The DIP is written and all necessary information are described in detail there with examples. The code also exists and there is even a pull request which has passed all the tests. Thus, this proposal is linked with not much work. Most of it was taken over by others.
Due to this, it really is not asking too much to get a note if this pull is accepted or rejected. Of course, with detailed justification.