April 21, 2013
On Sunday, 21 April 2013 at 02:13:54 UTC, Manu wrote:
> 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.
>

If that is your concern then the DIP36 is a very bad answer to it :
 - It require extra anotation, which wont be added most of the time.
 - It is inferior, and impair the introduction of lifetime. This isn't even discussed.
April 21, 2013
On Sunday, 21 April 2013 at 02:13:54 UTC, Manu wrote:
>>  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.

Yeah, that's kind of what I meant when I said it's a two-for-one deal. You get to pass temps, and you get safety checking too.
April 21, 2013
Well perhaps I am too hasty. I'll wait and see what is happening.

BTW: Thanks for the support. ;)
April 21, 2013
On Sunday, 21 April 2013 at 01:04:04 UTC, deadalnix wrote:
> 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.

At least some objections that make sense and I'd love to see in the very first announcement. If you see any issues that prevent treating "const scope int" as "const scope ref int", please tell about them and they will be addressed in DIP. Because it is the intention. I don't understand what aliasing are you speaking about.
April 21, 2013
On Sunday, 21 April 2013 at 02:50:02 UTC, deadalnix wrote:
> If that is your concern then the DIP36 is a very bad answer to it :
>  - It require extra anotation, which wont be added most of the time.

Automatic annotations are indicators of broken language. If someone will forget this one, he won't be able to use rvalues, no problem.

>  - It is inferior, and impair the introduction of lifetime. This isn't even discussed.

Scope is the absolute minimal lifetime which is needed for this DIP. Any other lifetime options are simply irrelevant.
April 21, 2013
On Sunday, 21 April 2013 at 02:50:02 UTC, deadalnix wrote:
> If that is your concern then the DIP36 is a very bad answer to it :
>  - It require extra anotation, which wont be added most of the time.

It's possible to make it an error to pass a stack variable to a non-'scope' ref parameter. Or to make it an error in @safe code only. But those may be extreme measures. This also raises the issue that some types of escape are more dangerous than others.

ref T func(ref T a) {
  return a; // Escape by return, @safe if tracked at call site
  T* p = &a; // Escape to local pointer, @safe? if *p is tracked
  static T* s = &a; // Escape by global pointer, @system
}

In this sense, 'scope' is a blunt instrument, because you might want to say, 'returnable, but not globally assignable'.

'scope' is also the kind of thing which might be better as the default than as something you must specifically add. But then we'd need an attribute '@noscope' or something like that. Ugh.

>  - It is inferior, and impair the introduction of lifetime. This isn't even discussed.

You've mentioned lifetime a couple times. Can you show what lifetime is and show how it contrasts with the current proposal, particularly DIP25?
April 21, 2013
On Sunday, 21 April 2013 at 10:55:37 UTC, Dicebot wrote:
>> 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.
>
> At least some objections that make sense and I'd love to see in the very first announcement. If you see any issues that prevent treating "const scope int" as "const scope ref int", please tell about them and they will be addressed in DIP. Because it is the intention. I don't understand what aliasing are you speaking about.

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.
April 21, 2013
On Sunday, 21 April 2013 at 16:08:55 UTC, Zach the Mystic wrote:
> 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.

('nice' in the sense that it would prove the suggestion to be unworkable as opposed to nice that it actually is unworkable...)
April 21, 2013
On Sunday, 21 April 2013 at 16:02:35 UTC, Zach the Mystic wrote:
> On Sunday, 21 April 2013 at 02:50:02 UTC, deadalnix wrote:
>> If that is your concern then the DIP36 is a very bad answer to it :
>> - It require extra anotation, which wont be added most of the time.
>
> It's possible to make it an error to pass a stack variable to a non-'scope' ref parameter. Or to make it an error in @safe code only. But those may be extreme measures.

No they aren't.

> This also raises the issue that some types of escape are more dangerous than others.

This is why the notion of lifetime is needed.

> 'scope' is also the kind of thing which might be better as the default than as something you must specifically add. But then we'd need an attribute '@noscope' or something like that. Ugh.
>

Inference is always a solution.

>> - It is inferior, and impair the introduction of lifetime. This isn't even discussed.
>
> You've mentioned lifetime a couple times. Can you show what lifetime is and show how it contrasts with the current proposal, particularly DIP25?

Here is a good link to start :
http://smallcultfollowing.com/babysteps/blog/2012/07/17/borrowed-pointer-tutorial/
April 21, 2013
On 04/21/2013 02:51 AM, Manu wrote:
> On 21 April 2013 06:51, Timon Gehr <timon.gehr@gmx.ch
> <mailto: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.

That is the intention, but this formulation is awfully imprecise. Hence nothing has been implemented.

void foo(scope ref int x){ ... }
void foo(scope int* x){ ... }
void foo(scope ref int* x){ ... }

// ???

struct S{
    scope S* x; // ???
}

> And as such, just happens to make passing a temporary
> by ref safe.
> ...

But this is not about safety! Passing an rvalue by ref is disallowed even in @system code. Hence 'scope' is assigned a meaning different from its intention. The DIP also aims to add more special behaviour to built-in literals.