What's wrong with passing a struct as scope ref const?

I want to avoid copying the struct, and its information is only read inside the function...

You're looking for 'in ref T'? I was also trying to do this today funnily enough, and it seems a shame this doesn't work. Is this a bug, or is it intended that it's not supported?

On 3 May 2012 21:28, Mehrdad <wfunction@hotmail.com> wrote:

> What's wrong with passing a struct as scope ref const?
>
> I want to avoid copying the struct, and its information is only read inside the function...
>

On Thursday, 3 May 2012 at 18:28:19 UTC, Mehrdad wrote:
> What's wrong with passing a struct as scope ref const?
>
> I want to avoid copying the struct, and its information is only read inside the function...

ref scope? hm? What additional semantics do you desire from that construct, which 'const ref' doesn't provide?

A a;

void fun(const scope ref A x)
{
  // x goes out of scope, destroy it... oops it's a global variable!?
}

fun(a);

On 05/03/2012 03:21 PM, Tove wrote:
> On Thursday, 3 May 2012 at 18:28:19 UTC, Mehrdad wrote:
>> What's wrong with passing a struct as scope ref const?
>>
>> I want to avoid copying the struct, and its information is only read
>> inside the function...
>
> ref scope? hm? What additional semantics do you desire from that
> construct, which 'const ref' doesn't provide?

scope is a not-yet-implemented promise of the function. It says: "trust me, I will not use this reference outside of the function."

> A a;
>
> void fun(const scope ref A x)
> {
> // x goes out of scope, destroy it... oops it's a global variable!?

scope does not destroy. scope makes this illegal (assuming that A is a class type):

    a = x;

There is deprecated use of the 'scope' keyword but this is not it.

> }
>
> fun(a);
>

Ali

On Thursday, 3 May 2012 at 22:25:45 UTC, Ali Çehreli wrote:
> On 05/03/2012 03:21 PM, Tove wrote:
> > On Thursday, 3 May 2012 at 18:28:19 UTC, Mehrdad wrote:
> >> What's wrong with passing a struct as scope ref const?
> >>
> >> I want to avoid copying the struct, and its information is
> only read
> >> inside the function...
> >
> > ref scope? hm? What additional semantics do you desire from
> that
> > construct, which 'const ref' doesn't provide?
>
> scope is a not-yet-implemented promise of the function. It says: "trust me, I will not use this reference outside of the function."
>
> > A a;
> >
> > void fun(const scope ref A x)
> > {
> > // x goes out of scope, destroy it... oops it's a global
> variable!?
>
> scope does not destroy. scope makes this illegal (assuming that A is a class type):
>
>     a = x;
>
> There is deprecated use of the 'scope' keyword but this is not it.
>
> > }
> >
> > fun(a);
> >
>
> Ali

right, thanks. I forgot about that, since it was never implemented I didn't use it.

But nevertheless... the actual implemented semantics is the same for parameters as for the deprecated function body case, at the end of the function the parameter goes out of scope too! i.e. destructor should be called.

On Thursday, 3 May 2012 at 22:43:16 UTC, Tove wrote:
>> scope does not destroy. scope makes this illegal (assuming that A is a class type):
>>
>>    a = x;
>>
>> There is deprecated use of the 'scope' keyword but this is not it.
>>
>> > }
>> >
>> > fun(a);
>> >
>>
>> Ali
>
> right, thanks. I forgot about that, since it was never implemented I didn't use it.
>
> But nevertheless... the actual implemented semantics is the same for parameters as for the deprecated function body case, at the end of the function the parameter goes out of scope too! i.e. destructor should be called.

Hmmm sorry for the confusion, I was living under the delusion that:

scope class A{}
void fun(scope A x){}
fun(new A());

did something, but it doesn't. ;)

On Friday, May 04, 2012 00:43:14 Tove wrote:
> But nevertheless... the actual implemented semantics is the same for parameters as for the deprecated function body case, at the end of the function the parameter goes out of scope too! i.e. destructor should be called.

No, it's not the same semantics. scope on parameters is all about preventing escaping - and in the case of delegates, provides the the additional benefit of indicating that allocating a closure is unnecessary. If you did something like

MyClass foo(scope MyClass c)
{
 ...
}

c would _not_ have its destructor called. Rather, the compiler would guarantee that no reference to c had escaped the function (e.g. by being returned). This is _completely_ different from doing

void foo()
{
 scope c = new MyClass;
}

which is being replaced by std.typecons.scoped.

- Jonathan M Davis

http://d.puremagic.com/issues/show_bug.cgi?id=8121