Is D 0.163 D 1.0?

[Lionello Lunesu]

Chad J wrote:
> 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) 
>>
>>
> 
> Myself I would prefer not to have that.  It creates an ambiguity between 
>  a static opCall on A and the storage attribute.

I think "static opCall" is a hack to begin with. It's basically a 
workaround for structs not having constructors. For classes, there's no 
point in having a static opCall if Walter implements the "A()" construct.

> I prefer the storage attribute have it's own keyword.  Perhaps give 
> storage 'auto' and type inference 'var'.  For me, that makes it more 
> obvious, since to my eyes it would be a keyword that I've never seen 
> before and now need to look up in the spec - otherwise it's just a 
> static opCall :(.

I also prefer "var" to "auto" for the type inference. I don't think 
anybody expects "var" to be dynamically typed. Well, maybe a few. And 
then there's the "auto" from C++; it might confuse people if its meaning 
were changed.

L.