On 03/10/2009 11:59, Denis Koroskin wrote:
On Sat, 03 Oct 2009 10:52:09 +0400, Christian Kamm
<kamm-incasoftw...@removethis.de> wrote:
Tom S wrote:
I think it should be done in userland, not built-in. Here's a
proof-of-concept implementation:
I agree and also had a go at it a few months back:
http://www.digitalmars.com/d/archives/digitalmars/D/scope_as_template_struct_82104.html
What about alignment issues though? I think we need to force that byte
array
with the class data to have the same alignment restrictions as the class
data.
Yes, it is possible, but their use is dangerous without non-nullable
*value* types, because user is not forced to initialize it in ctor.
I believe compiler should complain unless user explicitly assigns a
value to such variable:
class Foo
{
Scope!(Bar) bar;
this()
{
//bar.construct(args); - a no-go, use of an unassigned variable.
// How can compiler distinguish between bar.constract(args),
// which is allowed to be called on non-constructed object, and
// bar.doSomething(), which is not?
// Besides, it hides possibly existing Bar.construct method.
// bar = new Bar(args); - desirable syntax, but impossible w/o compiler
help
bar = Scope!Bar(args); // explicitly initialized
bar.doSomething(); // okay
}
}
I think we should either drop "scope" feature altogether in favor of
library solution, or extend it to scope classes.
The former is not possible unless there is a way to implement
scope(exit), scope(success) and scope(failure) in library, which I am
not aware of.
That's why I prefer built-in scope class members ATM.
Be it implemented in a compiler, should it be rebindable or not? Andrei
mentioned that it's probably not, but then it creates an inconsistency
with local scope variable (those are rebindable).
Another difference is that currently the following code is allowed:
Foo createFoo() {
return new FooDerivative();
}
scope Foo foo = createFoo(); // allocates on heap anyway, which might be
confusing
Shouldn't compiler complain in case scope variable is heap-allocated?
Shall we unify the two concepts (local and class member scope
variables)? If yes, then how?
I think scope should be completely removed from the language. it seems
to me like the register keyword in C.
this aspect of memory management would be better off as an optimization
by the compiler when applicable instead of user specified.
consider:
class B {...}
class A {
// desirable syntax:
// const B obj;
NonRebindable!B obj; // assume language support instead of template
this (args) { obj = new B(args); }
}
since obj is non-rebindable the compiler can optimize this without
requiring the user to specify "scope".
local variables in a function would have similar semantics:
void foo() {
NonRebindable!B = new B;
..
}
final classes and immutables can also scoped.
unless the user wants to explicitly handle memory with C malloc, I think
the best thing would be to separate lifetime management from memory
management. the programmer defines the lifetime of the data while the
language/compiler/runtime handle all other aspects like choosing stack
vs. heap, allocating and de-allocating (GC)
