Is D 0.163 D 1.0?

[Oskar Linde]

Derek skrev:
> On Tue, 25 Jul 2006 00:53:02 -0700, Walter Bright wrote:
> 
>> Derek wrote:
>>> On Mon, 24 Jul 2006 00:33:23 +0000 (UTC), Andrei Khropov wrote:
>>>
>>>> And what about double meaning of 'auto'?
>>> In general 'auto' is a poor choice for both meanings. 'auto' is obviously
>>> shorthand for automatic, but automatic what??? 
>>>
>>> Walter, given that 'auto' as a keyword is not going to be removed from the
>>> language, how can one currently declare a type-inferred variable that has
>>> RAII properties?
>>>
>> Regan Heath penned the solution I thought I'd posted a while back, but 
>> maybe I hadn't:
>>
>>> class A {}
>>>
>>> A a = new A(); //normal
>>> A a = A(); //destroyed at end of scope
>>>
>>> and with auto..
>>>
>>> auto a = new A(); //normal
>>> auto a = A(); //destroyed at end of scope
>>>
>>> Simple, elegant, obvious (IMO)
> 
> I'm sorry but I'm just not getting it. I just tried this example using
> v0.163 and it fails to compile. I did ask "how can one *CURRENTLY* declare
> ...". So I guess one can't do it just now and the example is something yet
> to be implemented. 
> 
> If so, it means that the opCall paradigm will be removed from classes. Is
> that intentional?

Walter said: "I'm hard pressed to see the point of them for classes anyway."

(http://www.digitalmars.com/d/archives/digitalmars/D/announce/1727.html)

> 
> And I assume that if the class was declared as ...
> 
>   auto class A {}
> 
> then every object declared with the class would have to be ..
> 
>   A a = A();
> or
>   auto a = A();

I would assume so too.

> But how does this proposed syntax handle variable-length arrays?
> 
>   char[] a = read(filename);

I didn't even know that it is possible to make raii-dynamic arrays. :)

> Is 'a' destroyed at end of scope?

I'd say, definitely not in the above case. It seems the proposed change 
would remove the ability to declare raii dynamic arrays. The workaround 
would be:

char[] t = read(filename);
scope(exit) delete t;

> It seems to me that the implied 'destroy at end of scope' idea is not a
> good one. It needs explicit designation to make it clear to readers and
> coders alike. That must also help compilers in detecting coding mistakes
> too.

I'm vaguely agreeing. :) Something a bit more explicit would make the 
code clearer.

/Oskar