Ary Borenszweig wrote:
> Why is this useful?

Many optimizations are possible if it can be unambiguously determined that an object's lifetime cannot exceed the lifetime of the function it is instantiated in.

By preventing taking the address of it, there's no way to escape a reference to it.

Walter Bright, el 13 de febrero a las 19:13 me escribiste:
> bearophile wrote:
> >Andrei Alexandrescu:
> >>Scope classes will be eliminated from the language.
> >
> >Isn't it better to remove scope classes after a good escape analysis is implemented in the front-end?
> 
> Escape analysis can still be used to put class instantiations on the stack - it's just that that will be a compiler optimization, not a user one.

LDC already have some heuristics for that: http://www.dsource.org/projects/ldc/browser/gen/passes/GarbageCollect2Stack.cpp


-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------

== Quote from Walter Bright (newshound1@digitalmars.com)'s article
> bearophile wrote:
> > Andrei Alexandrescu:
> >> Scope classes will be eliminated from the language.
> >
> > Isn't it better to remove scope classes after a good escape analysis is implemented in the front-end?
> Escape analysis can still be used to put class instantiations on the
> stack - it's just that that will be a compiler optimization, not a user one.

But the compiler has to be relatively conservative about this, whereas the user can take advantage of knowing how his/her program works at a high level.  That said, I'm in favor of removing scope classes from the core language because their RAII purpose has been taken over by structs and their optimization purpose should be fulfilled via an uglier, more dangerous looking and more general library construct.  Such a library construct should also allow strong class instances inline in other class instances.

dsimcha:
>Such a library construct should also allow strong class instances inline in other class instances.<

How can this be done? Is it possible to take any class and instantiate it with a placement new inside another class instance? I'd like to see a bit of the implementation code.

Thank you, bye,
bearophile

== Quote from bearophile (bearophileHUGS@lycos.com)'s article
> dsimcha:
> >Such a library construct should also allow strong class instances inline in
other class instances.<
> How can this be done? Is it possible to take any class and instantiate it with a
placement new inside another class instance? I'd like to see a bit of the implementation code.
> Thank you, bye,
> bearophile

Here's a quick and dirty implementation.  I haven't thought about how to work out all the details yet:

1.  If the class contains immutable members, this implementation allows for overwriting immutable data.

2.  I don't know how to give the struct proper type information so that the GC won't scan it if it doesn't contain any pointers.  Right now I'm using void[], which needs to always be conservatively scanned.

3.  The way I handled c'tors isn't going to work with ref parameters, etc.

import std.stdio;

struct InlineClass(C) {
    enum instanceSize = __traits(classInstanceSize, C);
    void[instanceSize] space = void;

    this(T...)(T args) {
        space[] = typeid(C).init[];
        instance.__ctor(args);
    }

    C instance() {
        return cast(C) cast(void*) &this;
    }

    alias instance this;
}

class Foo {
    uint n;

    this(uint startVal) {
        n = startVal;
    }

    void printN() {
        writeln("Called printN for the ", n++, "th time.");
    }
}

void main() {
    auto foo = InlineClass!Foo(5);
    foo.printN();
    foo.printN();
}

dsimcha:
> Here's a quick and dirty implementation.  I haven't thought about how to work out all the details yet:

Thank you for your code, I'll try it.
If some of the problems you talk about can't be currently solved, then I think D2 has to be improved/modified to allow all those problems to be fully solved :-) I think it's important to create a flexible language. That's why I have asked for some code here. If the language can't be modified enough to solve all those problems, then it's better to not remove (yet) the scope classes from D2 (the same is true for foreach_reverse).

Bye,
bearophile