On Saturday, 20 April 2013 at 16:11:49 UTC, Namespace wrote:
>> 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.

How about "on hold"? (Not that I have any say in it at all)

The fact is, there's much more to any change than simply implementing it. Changes break unexpected things. There are always extra corner cases not considered. There are always bugs and inconsistencies.

Although it's great that you and some others have done the legwork to implement this proposal, it may have to wait until other more urgent problems have been fixed.

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.


I thought D was driven by its community.

> How about "on hold"? (Not that I have any say in it at all)
As long as it is implemented in the near future and we must not wait another year (not even a half) it is ok.
But the fact is, that we don't know what state it has, because we get no response.

> The fact is, there's much more to any change than simply implementing it. Changes break unexpected things. There are always extra corner cases not considered. There are always bugs and inconsistencies.
Could be, but I don't see what could be broken by this DIP. All contingencies are listed also in the DIP (and that are not many). And it passed all tests what is crucial.

> Although it's great that you and some others have done the legwork to implement this proposal, it may have to wait until other more urgent problems have been fixed.
Could be, but I don't know why. Which other fix is necessary for this pull?
But also this would be ok, as long as we know, _which_ problems must be fixed.

On 04/20/2013 05:56 PM, Dicebot wrote:
> 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.

_New meaning_ is assigned to existing grammar whose original purpose is at most loosely related to the _new_ features.

I do not think that making 'scope' indicate an rvalue reference is particularly future proof.

On 04/20/2013 07:34 PM, Minas Mina wrote:
> ...
>
> I thought D was driven by its community.

(This is its community.)

On Saturday, 20 April 2013 at 14:42:57 UTC, Namespace wrote:
> 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.

I don't think that's true.

> The DIP was not much discussed and the pull request is regularly overlooked / ignored.

Patience!

> 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.

I think you've done a good job with the feature and the presentation.

But I personally don't feel like it's my job to rush D's development. Part of the reason is that D is already way ahead of most if not all of the competition in terms of sheer language design. When you extend into unknown territory, it's sometimes wise just to stay where you are for a bit, to give yourself time to adapt and build up a foundation.

I don't think your work will go unnoticed or unappreciated. Most of the time when people don't get back to you, it's because they're busy with other things. Probably the best thing you can do is say, well, my work on this feature is done, what else can I improve around here? This feature and this issue won't go away, IMO.

On 21 April 2013 06:51, Timon Gehr <timon.gehr@gmx.ch> wrote:

> On 04/20/2013 05:56 PM, Dicebot wrote:
>
>> 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.
>>
>
> _New meaning_ is assigned to existing grammar whose original purpose is at most loosely related to the _new_ features.
>
> I do not think that making 'scope' indicate an rvalue reference is particularly future proof.
>

That's not what scope does. Scope promises that the variables will not
escape the scope. And as such, just happens to make passing a temporary by
ref safe.
It does not implement r-value ref's. It simply allows refs to temporaries
to be considered a safe operation.

This DIP is actually likely to solve an important source of problems, consider:

void func(const ref matrix m);


func(x.getMatrix()); // compile error!

// fu*^&%$ing hell! you piece of &%^#≈¿$!
// ...

matrix temp = x.getMatrix();
func(temp); // no more compile error! (but equally unsafe/dangerous)


In this example, the 'solution', which is what everybody does right now, is
exactly as unsafe as the attempted call with the r-value.
ref, as in the language right now, is a fundamentally unsafe operation...
and not only is it technically unsafe, a programmer can't even know if it
is practically unsafe or not.
Since they have a habit of using this hack, they may unknowingly use it in
a call site where it's not *practically* safe to do it. They can't know,
and by habit (and frustration) they're trained to use this hack everywhere.

With 'scope ref' (or 'in ref'), the programmer now has a guide to say whether it's safe to pass a temporary or not. In the future, if the function does not receive scope ref, perhaps the programmer will start to presume that it is NOT safe to pass a temporary, and stop doing so via the current local-variable hack.

scope was always intended to implement this promise as far as I'm lead to
believe(?).

<Side rant>
In my experience showing D to new people, this is the #1 complaint. It's
the first one that comes up, every time (which really doesn't help with
first impressions), and I'm fairly sure every single person I've introduced
to D has complained about this.
It's kind of embarrassing when I'm saying that D is really cool, and then I
have to start making excuses and apologising for this, and assure them that
it's a known issue, and it'll be fixed one day.

On Saturday, 20 April 2013 at 18:00:50 UTC, Namespace wrote:
>> The fact is, there's much more to any change than simply implementing it. Changes break unexpected things. There are always extra corner cases not considered. There are always bugs and inconsistencies.
> Could be, but I don't see what could be broken by this DIP. All contingencies are listed also in the DIP (and that are not many). And it passed all tests what is crucial.
>

The DIP for instance, consider that const scope ref is semantically equivalent to pass by value, when it isn't (and not only for performance reasons, but for aliasing reasons). Nothing is considered about it.

On Sunday, 21 April 2013 at 00:51:31 UTC, Manu wrote:
> That's not what scope does. Scope promises that the variables will not
> escape the scope. And as such, just happens to make passing a temporary by
> ref safe.
> It does not implement r-value ref's. It simply allows refs to temporaries
> to be considered a safe operation.

It's a two-fer! (2 for 1 deal)

> This DIP is actually likely to solve an important source of problems,
> consider:
>
> void func(const ref matrix m);
>
>
> func(x.getMatrix()); // compile error!
>
> // fu*^&%$ing hell! you piece of &%^#≈¿$!
> // ...
>
> matrix temp = x.getMatrix();
> func(temp); // no more compile error! (but equally unsafe/dangerous)

It's hard to fully understand this example without getMatrix() defined, and why func() is unsafe (does it escape the reference?). Help!

> <Side rant>
> In my experience showing D to new people, this is the #1 complaint. It's
> the first one that comes up, every time (which really doesn't help with
> first impressions), and I'm fairly sure every single person I've introduced
> to D has complained about this.
> It's kind of embarrassing when I'm saying that D is really cool, and then I
> have to start making excuses and apologising for this, and assure them that
> it's a known issue, and it'll be fixed one day.

Yikes.

On 21 April 2013 11:36, Zach the Mystic <reachzach@gggggmail.com> wrote:

> On Sunday, 21 April 2013 at 00:51:31 UTC, Manu wrote:
>
>> That's not what scope does. Scope promises that the variables will not
>> escape the scope. And as such, just happens to make passing a temporary by
>> ref safe.
>> It does not implement r-value ref's. It simply allows refs to temporaries
>> to be considered a safe operation.
>>
>
> It's a two-fer! (2 for 1 deal)
>
>
>  This DIP is actually likely to solve an important source of problems,
>> consider:
>>
>> void func(const ref matrix m);
>>
>>
>> func(x.getMatrix()); // compile error!
>>
>> // fu*^&%$ing hell! you piece of &%^#≈¿$!
>> // ...
>>
>> matrix temp = x.getMatrix();
>> func(temp); // no more compile error! (but equally unsafe/dangerous)
>>
>
> It's hard to fully understand this example without getMatrix() defined,
> and why func() is unsafe (does it escape the reference?). Help!


definition:
  matrix getMatrix(T x); // this is all you know

That's the point of the example. You _don't know_ if func() is unsafe, does
it escape the reference? But you need to pass a temp anyway, you have no
bearing on whether you should just hack it to work, or reconsider the
problem.
And when 99 times out of 100, the correct answer is 'hack it to work',
you're basically asking for a spectacular bug in that other 1% of cases.


 <Side rant>
>> In my experience showing D to new people, this is the #1 complaint. It's
>> the first one that comes up, every time (which really doesn't help with
>> first impressions), and I'm fairly sure every single person I've
>> introduced
>> to D has complained about this.
>> It's kind of embarrassing when I'm saying that D is really cool, and then
>> I
>> have to start making excuses and apologising for this, and assure them
>> that
>> it's a known issue, and it'll be fixed one day.
>>
>
> Yikes.
>