On 4/20/13 11:17 AM, 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.

In a way I wish my not being polite would be the main bottleneck for this. I've been extremely busy at work, then preparing for DConf 2013, and last week has been quite distracting what with the Boston bombings three miles away from where we live and all that. It strikes me as odd to be obligated to spend time on something just because someone else did, and framed as impolite if I don't.

That being said, I have made a pass through this DIP and I have the following concerns about it.

1. It defines a new language feature instead of improving the existing ones. At this point in the development of the language, our preference should be putting the existing features in good order.

2. The proposal is sketchy and does not give many details, such as the lifetime of temporaries bound to scope ref objects.

3. The relationship with auto ref is insufficiently described, e.g. there should be clarification on why auto ref cannot be improved to fulfill the desired role.

4. Above all this is a new language feature and again we want to resort to adding new feature only if it is clear that the existing features are insufficient and cannot be made sufficient. In particular we are much more inclined to impart real, demonstrable safety to "ref" and to make "auto ref" work as a reference that can bind to rvalues as well as lvalues.


Andrei

On Monday, 22 April 2013 at 12:22:14 UTC, Diggory wrote:
> Why not simply make escaping a "ref" pointer an unsafe operation. The compiler should be able to detect this and report it without any changes to the syntax.

In other words, 'scope' would be the default and require no explicit attribute. The first thing about this is the question of how much code it would break. I don't know the answer. Maybe a mockup of this idea could be used to create a sense of how badly it breaks existing code. The second question is how desirable is it as a feature. I think it may be quite desirable to have all refs be 'scope' by default, because the most common case will be the default, that refs will not be assigned to globals. Since there is a difference between the safety of returning by ref and the safety of assigning to heap or global addresses, there may need to be a distinction made between these two types of 'escape'.

> This should cover 99% of cases with no extra attributes required and no limitations on what you can do with a "ref" within the function. In the 1% of cases that a pointer needs to be escaped safely you can add an attribute (maybe "heap ref" or something, although perhaps some existing syntax could be used) that requires the input to have been allocated on the heap.

'@noscope ref' has also been suggested, since the reference in question would also need to include static global data.

> In the case that a stack variable is passed as a "heap ref" parameter the compiler can automatically promote it where possible, or if that's not possible, such as the variable being marked "scope" (existing meaning) then it should complain.

This is interesting to me. The only drawback I can think of is the aversion people have to introducing code which could secretly allocate, since many people want to avoid the garbage collector. It would only be an issue if the automatic promotion looked so much like a normal function call that it was extraordinarily difficult to distinguish it.

> As far as I'm aware the only real purpose for R-value references is to implement move semantics. This could already be done using "ref in" syntax, as that makes no guarantees that the value is not going to be destroyed, only says that the value should be initialised prior to it being passed in. The only change would be to allow passing temporaries as "ref in".

The only existing definition of 'in' is that it means 'const scope', so it already means scope. I don't know if that is a good definition or not. I think that there remains a significant fear in this community of introducing changes which will break existing code. I don't myself know how justified this fear is, but it is nonetheless something to take very seriously when proposing new ideas.

> I realise I'm new here

I'm new too. I'm glad to be able to have this discussion with you despite both of our being new. :-)

On Monday, 22 April 2013 at 20:02:12 UTC, Andrei Alexandrescu wrote:
> 4. Above all this is a new language feature and again we want to resort to adding new feature only if it is clear that the existing features are insufficient and cannot be made sufficient. In particular we are much more inclined to impart real, demonstrable safety to "ref" and to make "auto ref" work as a reference that can bind to rvalues as well as lvalues.

Why isn't DIP36 "scope ref" be future compatible with a future safe "auto ref"?

... and if in the future the compiler would be able to infer "scope ref" from "auto ref", this entire DIP could be reused, with the benefit that people could start using this functionality already today(there is a full pull request with a very small delta), before the auto inference is in place.

> In a way I wish my not being polite would be the main bottleneck for this. I've been extremely busy at work, then preparing for DConf 2013, and last week has been quite distracting what with the Boston bombings three miles away from where we live and all that. It strikes me as odd to be obligated to spend time on something just because someone else did, and framed as impolite if I don't.
>
> That being said, I have made a pass through this DIP and I have the following concerns about it.
>
> 1. It defines a new language feature instead of improving the existing ones. At this point in the development of the language, our preference should be putting the existing features in good order.
>
> 2. The proposal is sketchy and does not give many details, such as the lifetime of temporaries bound to scope ref objects.
>
> 3. The relationship with auto ref is insufficiently described, e.g. there should be clarification on why auto ref cannot be improved to fulfill the desired role.
>
> 4. Above all this is a new language feature and again we want to resort to adding new feature only if it is clear that the existing features are insufficient and cannot be made sufficient. In particular we are much more inclined to impart real, demonstrable safety to "ref" and to make "auto ref" work as a reference that can bind to rvalues as well as lvalues.
>
>
> Andrei

I'm sorry that you take it so personally, but I know from experience that some topics often get forgotten or ignored if you don't ask about it more then once.
And that we have made so much effort should show that we work for D and not against it and that we don't want to annoy you.

But you are right, scope ref is in comparison to auto ref a new feature, but it is one with little sideeffects and minimized implementation effort.
And Jonathan described here (http://forum.dlang.org/thread/uswucstsooghescofycp@forum.dlang.org?page=2#post-mailman.293.1364249651.4724.digitalmars-d-learn:40puremagic.com) very well and in detail why auto ref is no solution for non-templates.
In short:
It cannot work the same way for non-templates as it does for template functions, because that would mean that non-templates are also doubled 2^n times.
And the way scope ref would work, would mean, that auto ref works different for templates and non-template functions.
But you'd better read Jonathan's answer.

On Monday, 22 April 2013 at 20:02:12 UTC, Andrei Alexandrescu wrote:
> In a way I wish my not being polite would be the main bottleneck for this. I've been extremely busy at work, then preparing for DConf 2013, and last week has been quite distracting what with the Boston bombings three miles away from where we live and all that. It strikes me as odd to be obligated to spend time on something just because someone else did, and framed as impolite if I don't.

Thanks for your time. Sometimes even simple "Have seen it, will answer later / after DConf is priceless".

> That being said, I have made a pass through this DIP and I have the following concerns about it.
>
> 1. It defines a new language feature instead of improving the existing ones. At this point in the development of the language, our preference should be putting the existing features in good order.

You consider "scope" a new language feature? And consider "auto ref" improvable solution. The very point of this DIP is to not create syntax-driven features, instead better define existing ones that make sense on their own so they can be used for same purpose.

> 2. The proposal is sketchy and does not give many details, such as the lifetime of temporaries bound to scope ref objects.

It can't because lifetime of temporaries is not defined in D at all and suck stuff needs to be consistent. It is not really different from a lifetime of struct literal temporary used for pass-by-value.

> 3. The relationship with auto ref is insufficiently described, e.g. there should be clarification on why auto ref cannot be improved to fulfill the desired role.

auto ref is a template-world entity. If by "improved" you mean "completely reworked" than sure, I can add this rationale. Will do today.

> 4. Above all this is a new language feature and again we want to resort to adding new feature only if it is clear that the existing features are insufficient and cannot be made sufficient. In particular we are much more inclined to impart real, demonstrable safety to "ref" and to make "auto ref" work as a reference that can bind to rvalues as well as lvalues.

Can't agree. "scope" is defined (but not implemented, a pity). Creating temporaries already exists for some cases. No really new language feature is added. No special syntax created. "scope ref" is still "scope" and "ref" with all semantics this imposes, rvalue references are just a side-effect. Contrary to this, "auto ref" IS a new feature created specifically for syntax hack. That is a very problem you are speaking about - introducing new concepts instead of making use of ones that exist for ages.

On Sunday, 21 April 2013 at 22:16:14 UTC, Timon Gehr wrote:
>> Passing an r-value by ref is disallowed for arbitrary reasons.
>
> Reasons not closely related to lack of 'scope'. So why bind the new rule to scope?

I had quite an impression this was prohibited mostly because of @safe issues.

On Wednesday, 10 April 2013 at 06:11:29 UTC, Zach the Mystic wrote:
> no value type is ever unsafe.


Delegates?

On Sunday, 21 April 2013 at 16:08:55 UTC, Zach the Mystic wrote:
> The only thing I could think of was if you want to 'ref' a reference type.
>
> void func(ref Object o, scope Object o2, scope ref Object o3) {}
>
> Would there be a difference between the type of o and o2, or of o2 and o3? There is inconsistency, but it would be nice to find use cases which make this inconsistency truly unworkable with other things in the language.

Taking consistent approach with "ref", they all should have same type but bpth "ref" and "scope" differences are mangled into func name so that caller can take notion of proper behavior. I don't see an issue here.

On Wednesday, 10 April 2013 at 07:39:25 UTC, Zach the Mystic wrote:
> ...

Kind of. I am thinking that scope is best when transitive for aggregation but not for indirection:

struct S { int a; int *b; }

void foo(scope S s)
{
    static int *x1 = &(s.a); // error
    static int *x2 = s.b; // fine
}

On 04/23/2013 10:10 AM, Dicebot wrote:
> On Sunday, 21 April 2013 at 22:16:14 UTC, Timon Gehr wrote:
>>> Passing an r-value by ref is disallowed for arbitrary reasons.
>>
>> Reasons not closely related to lack of 'scope'. So why bind the new
>> rule to scope?
>
> I had quite an impression this was prohibited mostly because of @safe
> issues.

It is disallowed in @system code.