auto, var, raii,scope, banana

[Bruno Medeiros]

Regan Heath wrote:
> On Tue, 25 Jul 2006 10:17:13 -0700, kris <foo at bar.com> wrote:
>> Don has a good point: changing to "var" would cause conflict with 
>> existing variable-names.
>>
>> Chad et. al. also have a good point about the conflict regarding 
>> static opCall() (via the lack of a "new" keyword). I suspect many 
>> people find the use of "new" to be indicative of allocation, and 
>> breaking this consistency may have a detrimental effect? Further, it 
>> was noted that a missing "new" can only be used at the instantiation 
>> site -- not at the class decl -- thus, D would be losing an existing 
>> feature.
>>
>> I suspect you could count the current number of raii-class uses on a 
>> few hands, whereas the use of "auto" for implied-type is pretty darned 
>> popular -- and rightly so, since it's really very, very useful. 
>> Changing the raii style to use a different keyword, whilst retaining 
>> implied-type "auto" would be an almost imperceptible change?
>>
>> Thus, it would appear to make sense to retain "auto" for implied-type, 
>> and introduce something *else* for automatic cleanup at end-of-scope 
>> (and also as a class attribute). how about reusing the "scope" keyword?
>>
>> void main()
>> {
>>    auto i = 10;
>>    auto foo = new Foo;
>>    auto scope bar = new Bar;
>>    auto scope wumpus = new Wumpus;
>> }
>>
>> class Foo {}
>>
>> class Bar {}
>>
>> scope class Wumpus {}
> 
> I say lets keep 'auto' for auto type inference (for the reasons you and 
> Don mention)
> 
> I like the use of scope at class decl. But, I prefer the no keyword 
> approach at instantiation. So, allow me to suggest this as a 3rd option.
> 
> - 'scope' at class decl.
> - no keyword at instatiation.
> 
> Reasoning:
> 
> 'new' implies heap allocation to me. It would be beneficial to allow the 
> compiler to allocate an RAII type in any way it wants, perhaps stack 
> allocating it. Removing 'new' removes the implied heap allocation 
> allowing the compiler to allocate however it likes.
> 
> I don't see the utility in static opCall, I say abolish/remove it. 
> Non-static opCall on the other hand can be quite useful.
> 
> Regan

I don't like the no-allocator-keyword proposal. There are the problems:
* the lack of static opCall (which I don't have experience with, so I'll
leave the arguing about the usefulness of it to others).
* less clear in the code that an allocation (stack or otherwise) is
taking place. (somewhat subjective/aesthetical point I guess)
But most importantly:
* You can't make auto objects out of objects allocated with a function
(like a factory method) instead of inline allocation. For example, the
following cannot be made with a no-allocator-keyword syntax:
   auto Foo foo = SomeFactory.newFoo(..); // can't make an auto here
   auto char[] a = read(filename); // can't make an auto here

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D