On Sunday, 6 August 2017 at 15:24:55 UTC, Jacob Carlborg wrote:
> On 2017-08-05 19:08, Johnson Jones wrote:
>> using gtk, it has a type called value. One has to use it to get the
>> value of stuff but it is a class. Once it is used, one doesn't need it.
>>
>> Ideally I'd like to treat it as a struct since I'm using it in a
>> delegate I would like to minimize unnecessary allocations. Is there any
>> way to get D to allocate a class on the stack like a local struct?
>
> Prefix the variable declaration with "scope":
>
> scope foo = new Object;

If you use this option, do be aware that this feature has been scheduled for future deprecation [1].
It's likely going to continue working for quite a while (years), though.

[1] https://dlang.org/deprecate.html#scope%20for%20allocating%20classes%20on%20the%20stack

On 2017-08-06 17:47, Moritz Maxeiner wrote:

> If you use this option, do be aware that this feature has been scheduled
> for future deprecation [1].
> It's likely going to continue working for quite a while (years), though.

It's used all over the place in the DMD code base.

-- 
/Jacob Carlborg

On Sunday, 6 August 2017 at 15:47:43 UTC, Moritz Maxeiner wrote:

> If you use this option, do be aware that this feature has been scheduled for future deprecation [1].
> It's likely going to continue working for quite a while (years), though.
>
> [1] https://dlang.org/deprecate.html#scope%20for%20allocating%20classes%20on%20the%20stack

FYI:  http://forum.dlang.org/post/np1fll$ast$1@digitalmars.com

"Yes, it will have to be updated - but I didn't want to adjust it before DIP1000 spec is finalized. Rationale that was driving deprecation of scope storage class is becoming obsolete with DIP1000 implemented but not before."

Mike

On Monday, 7 August 2017 at 10:50:21 UTC, Mike wrote:
> On Sunday, 6 August 2017 at 15:47:43 UTC, Moritz Maxeiner wrote:
>
>> If you use this option, do be aware that this feature has been scheduled for future deprecation [1].
>> It's likely going to continue working for quite a while (years), though.
>>
>> [1] https://dlang.org/deprecate.html#scope%20for%20allocating%20classes%20on%20the%20stack
>
> FYI:  http://forum.dlang.org/post/np1fll$ast$1@digitalmars.com
>
> "Yes, it will have to be updated - but I didn't want to adjust it before DIP1000 spec is finalized. Rationale that was driving deprecation of scope storage class is becoming obsolete with DIP1000 implemented but not before."

Thanks, I wasn't aware of this. I tried fooling around scope classes and DIP1000 for a bit and was surprised that this is allowed:

---
import core.stdc.stdio : printf;
import std.algorithm : move;

class A
{
	int i;

	this() @safe
	{
		i = 0;
	}
}

void inc(scope A a) @safe
{
	a.i += 1;
}

void print(scope A a) @trusted
{
	printf("A@%x: %d\n", cast(void*) a, a.i);
}

auto makeA() @safe
{
	scope a = new A();
	a.print();
	return move(a);
}

void main() @safe
{
	auto a = makeA();
	foreach (i; 0..10) {
		a.print();
		a.inc();
	}
}
---

You can still create a (scope) class on the stack, escape a reference to it using `move` and use it afterwards, all within the rules of @safe, so I'm not convinced that the reason for deprecating scoped classes is gone yet.
Compare this to `scoped`, which behaves as expected (since it wraps the reference type object in a value type):

---
import std.typecons : scoped;

auto makeA() @trusted
{
	auto a = scoped!A();
	a.print();
	return move(a);
}

void main() @trusted
{
	auto a = makeA();
	foreach (i; 0..10) {
		a.print();
		a.inc();
	}
}
---

On Monday, 7 August 2017 at 13:40:18 UTC, Moritz Maxeiner wrote:
>
> Thanks, I wasn't aware of this. I tried fooling around scope classes and DIP1000 for a bit and was surprised that this is allowed:
>
> ---
> import core.stdc.stdio : printf;
> import std.algorithm : move;
>
> class A
> {
> 	int i;
>
> 	this() @safe
> 	{
> 		i = 0;
> 	}
> }
>
> void inc(scope A a) @safe
> {
> 	a.i += 1;
> }
>
> void print(scope A a) @trusted
> {
> 	printf("A@%x: %d\n", cast(void*) a, a.i);
> }
>
> auto makeA() @safe
> {
> 	scope a = new A();
> 	a.print();
> 	return move(a);
> }
>
> void main() @safe
> {
> 	auto a = makeA();
> 	foreach (i; 0..10) {
> 		a.print();
> 		a.inc();
> 	}
> }
> ---
>
> You can still create a (scope) class on the stack, escape a reference to it using `move` and use it afterwards, all within the rules of @safe, so I'm not convinced that the reason for deprecating scoped classes is gone yet.
> Compare this to `scoped`, which behaves as expected (since it wraps the reference type object in a value type):
>
> ---
> import std.typecons : scoped;
>
> auto makeA() @trusted
> {
> 	auto a = scoped!A();
> 	a.print();
> 	return move(a);
> }
>
> void main() @trusted
> {
> 	auto a = makeA();
> 	foreach (i; 0..10) {
> 		a.print();
> 		a.inc();
> 	}
> }
> ---

Forgot to add the runtime output after compiling with `dmd a.d -dip1000`:

For `scope A`:
A@198d1568: 0
A@198d1568: 0
A@198d1568: 1
A@198d1568: 2
A@198d1568: 3
A@198d1568: 4
A@198d1568: 5
A@198d1568: 6
A@198d1568: 7
A@198d1568: 8
A@198d1568: 9

For `scoped!A`:
A@8de538b8: 0
A@8de53940: 0
A@8de53940: 1
A@8de53940: 2
A@8de53940: 3
A@8de53940: 4
A@8de53940: 5
A@8de53940: 6
A@8de53940: 7
A@8de53940: 8
A@8de53940: 9

On Monday, 7 August 2017 at 10:42:03 UTC, Jacob Carlborg wrote:
> On 2017-08-06 17:47, Moritz Maxeiner wrote:
>
>> If you use this option, do be aware that this feature has been scheduled
>> for future deprecation [1].
>> It's likely going to continue working for quite a while (years), though.
>
> It's used all over the place in the DMD code base.

I don't see how that's a reason for increasing the amount of code that needs to be changed if/when scope classes are deprecated. Mike's argument holds, though (if the loophole I pointed out gets fixed and scope classes are removed from the future deprecation list).

On Monday, 7 August 2017 at 13:42:33 UTC, Moritz Maxeiner wrote:

>> You can still create a (scope) class on the stack, escape a reference to it using `move` and use it afterwards, all within the rules of @safe, so I'm not convinced that the reason for deprecating scoped classes is gone yet.
>> Compare this to `scoped`, which behaves as expected (since it wraps the reference type object in a value type):

Looks like a bug to me.  I recommend submitting a bug report and tag it somehow with "scope" and/or "DIP1000".  It appears Walter is giving any bugs with scope/DIP1000 priority.

Mike

On Monday, 7 August 2017 at 22:02:07 UTC, Mike wrote:
> On Monday, 7 August 2017 at 13:42:33 UTC, Moritz Maxeiner wrote:
>
>>> You can still create a (scope) class on the stack, escape a reference to it using `move` and use it afterwards, all within the rules of @safe, so I'm not convinced that the reason for deprecating scoped classes is gone yet.
>>> Compare this to `scoped`, which behaves as expected (since it wraps the reference type object in a value type):
>
> Looks like a bug to me.  I recommend submitting a bug report and tag it somehow with "scope" and/or "DIP1000".  It appears Walter is giving any bugs with scope/DIP1000 priority.

Thanks for the feedback, done: https://issues.dlang.org/show_bug.cgi?id=17730

On Sunday, 6 August 2017 at 15:47:43 UTC, Moritz Maxeiner wrote:
> If you use this option, do be aware that this feature has been
 > scheduled for future deprecation [1].
> It's likely going to continue working for quite a while (years), though.
>
> [1] https://dlang.org/deprecate.html#scope%20for%20allocating%20classes%20on%20the%20stack

I can't understand. Why is moved a scope allocation to a library. I'm pretty sure it should be a language feature.

On Tuesday, 8 August 2017 at 05:37:41 UTC, ANtlord wrote:
> On Sunday, 6 August 2017 at 15:47:43 UTC, Moritz Maxeiner wrote:
>> If you use this option, do be aware that this feature has been
>  > scheduled for future deprecation [1].
>> It's likely going to continue working for quite a while (years), though.
>>
>> [1] https://dlang.org/deprecate.html#scope%20for%20allocating%20classes%20on%20the%20stack
>
> I can't understand. Why is moved a scope allocation to a library. I'm pretty sure it should be a language feature.

The reason is given at the link under "Rationale":

---
scope was an unsafe feature. A reference to a scoped class could easily be returned from a function without errors, which would make using such an object undefined behavior due to the object being destroyed after exiting the scope of the function it was allocated in. To discourage it from general-use but still allow usage when needed a library solution was implemented.

Note that scope for other usages (e.g. scoped variables) is unrelated to this feature and will not be deprecated.
---

Do note that - as Mike pointed out - this rationale does predate DIP1000 escape analysis and is largely invalidated by it for @safe code.
Another reason to use the library type is the ability to move the class object around via std.algorithm.move (if you need such C++ style behaviour); I'm not sure whether scope classes will get this feature (I have argued for it at the bug report linked to in my response to Mike), but I wouldn't count on it.