Suggestion: shortcut for 'new X' #2

[Kristian]

On Wed, 06 Sep 2006 05:07:33 +0300, Derek Parnell  
<derek at nomail.afraid.org> wrote:

> On Wed, 06 Sep 2006 02:20:01 +0200, Ivan Senji wrote:
>
>> Derek Parnell wrote:
>>> On Tue, 05 Sep 2006 20:35:13 +0200, Ivan Senji wrote:
>>>
>>>> Kristian wrote:
>>>>> Ok, I think my previous suggestion for an optional shortcut was a bit
>>>>> too strange... For example:
>>>>>
>>>>> Foo f = new Foo;
>>>>> Bar b = new Bar(10);
>>>>>
>>>>> <->
>>>>>
>>>>> Foo f = new;
>>>>> Bar b = new(10);
>>>>>
>>>>> Now there has been a proposal of the following (I use 'local' keyword
>>>>> here):
>>>>>
>>>>> Foo f1 = local Foo;  //stack/RAII
>>>>> Foo f2 = new Foo;    //heap
>>>>>
>>>>> I like the syntax also.
>>>>>
>>>>> How about if you could *alternately* write:
>>>>>
>>>>> local Foo f1;
>>>>> new Foo f2;
>>>>>
>>>>> This would take care of the redundant class name in the declarations.
>>>>>
>>>>> (I just hate redundance! ;) Writing class names twice is frustrating;
>>>>> there is a pattern of "X ... X".)
>>>>>
>>>>> Constructor parameters are put after variable names:
>>>>>
>>>>> local Bar b(10);
>>>>> new Bar b(10, true);
>>>>>
>>>>> If this (or something similar) is not possible, a lot of people
>>>>> (including me) could end writing auto typed declarations. For example
>>>>> (auto here means auto type, not RAII):
>>>>>
>>>>> auto f = new Foo;
>>>>> auto b = new Bar(10);
>>>> And I still don't see what is so terribly awful about that?
>>>>
>>>>> That could be shortened to:
>>>>>
>>>>> f = new Foo;
>>>>> b = new Bar(10);
>>>>>
>>>>> Which leads to my suggestion:
>>>>>
>>>>> new Foo f;
>>>>> new Bar b(10);
>>>> Hmm, that looks a little to strange to me. It looks more like an
>>>> expression than a declaration.
>>>
>>> The suggestion looks good to me. I see the same form ...
>>>
>>>  static int a;
>>>  new    Foo b;
>>>
>>> so to generalize ...
>>>
>>> DATADECLARATION ::   [STORAGECLASS] TYPE IDENTIFIER [ARGUMENTS]
>>>
>>>          int   a;
>>>   new    Foo   b;
>>>   local  Bar   c;
>>>   static float e;
>>>
>>
>> OK, now I know why it looked strange.. :)
>>
>> Class references when normally created would be null, and you have to
>> assign something to them for them to be something other than null.
>>
>> And with this syntax there is explicit assignment :)
>
> Good point. But there doesn't have to be an assignment. For example...
>
>   local Foo a;   // Creates a null Foo object reference
>   new   Foo b;   // Also creates a null Foo object reference
>
>   local Foo c();   // Creates a Foo object reference and object instance
>                    // on the stack with the dtor called when leaving  
> scope.
>   new   Foo d();   // Creates a null Foo object reference and object
>                    // instance on heap with no guaranteed dtor call.
>                    // This is a shorthand for 'Foo d = new Foo();'

If you like that it would be possible to create null object references  
with this syntax, I think I can live with the extra parenthesis when  
creating object instances... ;)

The compiler could then do the following checks:

local Foo a;
new   Foo b;

a = local Foo;  //ok
a = new Foo;    //error

b = local Foo;  //error
b = new Foo;    //ok


>> But is a bigger problem maybe that there are going to be too many ways
>> to write the same thing?
>>
>> Foo b = new Foo;
>> auto b = new Foo;
>> new Foo b;
>
> Maybe, but we don't have a way to do 'auto auto ...' yet.
>

I don't think this is a big problem because variable declaration is a  
simple thing, easy to read and understand. It's a matter of being  
consistent.

And if 'local' and 'new' here are treaded as storage classes (i.e. "local  
Foo a;" creates a null object reference) and the parenthesis syntax is a  
shortcut notation (i.e. "local Foo a();" creates an object reference and  
an object instance), then we have:

Foo a;            //a = null
local Foo b;      //b = null
local Bar c(10);  //c = local Bar(10)



Hmm, what if you could put all the init values inside parenthesis...? For  
example:

int a(5);   //== "int a = 5;"
Bar b(10);  //== "Bar b = new Bar(10);"

Well, I am not sure if I like it. It makes "a(5)" to look like a class  
object with a constructor... but one could think that an initialization is  
a some kind of constructor... I have to think about it. Comments?