this() not executing code on structs

[Steven Schveighoffer]

On Thu, 22 Oct 2009 12:50:21 -0400, grauzone <none at example.net> wrote:

> dsimcha wrote:
>> == Quote from grauzone (none at example.net)'s article
>>> Andrei Alexandrescu wrote:
>>> I'd really like to know why "scope x = new X();" is "unsafe", while
>>> encouraging doing exactly the same with structs seems to be a perfectly
>>> fine idea. Allocating structs on the stack is obviously not any safer
>>> than with classes. I don't remember the exact reasons why you wanted to
>>> turn "scope" into a library feature, but I think I remember something
>>> about discouraging it for safety reasons; please forgive me is this is
>>> wrong.
>>  Because classes in D are always passed by pointer.  (Technically  
>> references, but
>> really they're just pointers under the hood.)  Returning a scope  
>> (stack-allocated)
>> class from a function is equivalent to escaping a pointer to a stack  
>> variable.
>> Returning a struct is done by value, just like returning an int.
>
> (I'm talking about scope classes as declared in "scope class T { ... }")

Your original question was about the statement "scope x = new X()", which  
can be done on any type of class, even non-scope ones.


> But you can't return scope classes from a function. You can't pass them  
> as ref parameters either. They're designed to be safe.
>
> On the other hand, you can pass struct pointers all the way you want  
> around, and it's damn unsafe.
>
> I don't get this "structs are safe because they are value types"  
> argument anyway, because the this pointer for structs is a  
> pointer/reference anyway. If it's trivial to break that "safety", can  
> you really call it "safety"?

Passing struct pointers is not always the norm.  Passing class references  
*is* the norm (and actually the only way), even for scope classes, so  
there is much more chance for escape.

>
>> Scope is really a dangerous hack to allocate a *reference type* on the  
>> stack.
>> It's dangerous and kludgey, but in a performance-oriented language it's  
>> a
>> necessary evil.
>
> You could say the same about structs.

You have to go out of your way to pass a struct by reference.  You *can't*  
possibly pass a class by value, so they are more dangerous.

In order to make scope safer, it has to be a type modifier in addition to  
a storage class, so the compiler can make reasonable decisions (like  
disallowing implicit casting to a non-scope version).

<OT>

> Why do all objects have monitor pointers anyway? The idea, that every  
> object can act as lock, is a really bad one. But this is off-topic...

All objects have a *placeholder* for a lock, which isn't allocated until  
the object is locked for the first time.  It's a very pervasive idea in  
other successful languages like Java and C#.  Having used it extensively  
in C#, I find it very easy to use and well designed.

However, in C#, there is support for conditions on objects as well, which  
isn't "builtin" for D.  IMO, mutexes without conditions is severely  
limiting.  The library condition variables aren't as nice as C#'s builtin  
conditions.
</OT>

-Steve