auto, var, raii,scope, banana

[xs0]

Regan Heath wrote:

>> 'new' doesn't imply/require that heap allocation actually be done, it 
>> just requires the result to behave as if it was (look up "escape 
>> analysis")
> 
> Ok.
> 
>>>> Besides speed, is there any reason at all to allocate on the stack?
>>>  Speed isn't a good enough reason?
>>
>> Speed is a good reason to use stack allocation. But that is also a 
>> good reason to let the compiler determine where to place an object, 
>> not the programmer.
> 
> Exactly. I never suggested otherwise :)

You did - you propose that using "new" forces the allocation on the 
heap, while not using it leaves the choice to the compiler (however, the 
variable is then also scoped/raii/auto/banana, so there's not much 
choice anyway).


>>>  Is it even possible for 'new' to allocate on the stack? I mean the 
>>> stack vanishes when the function exits, therefore isn't 'new' 
>>> restricted to the heap?
>>
>> No. There are many cases where the object is not actually required to 
>> be on the heap.
> 
> Example?

Did you look up escape analysis like I suggested? Anyway, besides the 
obvious scoped/raii/auto/banana variables, here's a simple example:

void foo(Object a)
{
     writefln("%s", a.toString());
}

main()
{
     foo(new Whatever());
}

There's no reason why Whatever would have to be on the heap.


>>>> Imho, "scope" is a perfect keyword for scoped variables/classes, for 
>>>> reasons already stated (already exists, good meaning, explicit). A 
>>>> missing "new" is not a good keyword ;)
>>>  I disagree, see my recent reply to "Chad J", specifically the 
>>> scenarios involving the C++ and Java programmers.
>>
>> Well, I'm a Java programmer and if I see
>>
>> A a = A();
>>
>> I see a function call that returns something of type A. If I see
>>
>> auto a = A();
>>
>> I definitely see a function call. You'll never convince me that the 
>> lack of "new" is a good indication of anything, much less of the fact 
>> that it's a scoped variable.
> 
> Have you read my other post?
> Are you telling me you have a "closed mind"?
> If so, this discussion is pointless.

Dude, what's wrong with you? Your argument was that Java programmers 
would see an allocating expression without "new" or any other keyword, 
and somehow magically determine that there's something to be learned. I 
responded by saying that they (or me) wouldn't even see it as an 
allocating expression, and for that I have a closed mind? You know, 
you're probably right, this discussion is pointless, like so many others 
you participate in.

And I still don't get how you can even think that "" can be a better 
indication of anything than "scope" (or any other keyword). When you see 
an empty paper, does a thought "oooh, I need to learn about D's scoped 
variables" spring to your mind?


>>> The only utility in static opCall is to emulate a constructor. Why 
>>> not replace them with a constructor (ie. rename "static opCall" to 
>>> "this"). Then, remove static opCall altogether.
>>
>> Emulating a constructor is not the only utility, it's emulating an 
>> arbitrary function.
> 
> Yes, but it's a 'static' function. See my other post WRT "information 
> hiding", for that purpose it's actually better to use an actual static 
> function.

Without even reading your other post, I never said it's always better to 
use static opCall. I'm just saying there are cases where it's cool to 
have. But, this is basically a separate discussion anyway, so no need to 
continue with it.


xs0