Hi all,

I guess D syntax can allow implicit new expression like following:

class C {
  this() {}
  this(int x) {}
}
void func() {
  C c = C();  // not new C()
  c = C(3);   // not new C(3)
}

I think the syntax is cute. And the syntax is not ambiguous and does not make DMD slower. I have succeeded to implement the syntax into GDC-0.18 (based on DMD-0.157). The following patch worked.

4076,4078c4076,4080
< //        fd = search_function(ad, Id::call);
< //        if (fd)
<           {
---
>           Expression *e = new DotIdExp(loc, e1, Id::call);
>           if (dynamic_cast<TypeExp *>(e1)) {
>               e = new NewExp(loc, NULL, e1->type, arguments);
>               return e->semantic(sc);
>           } else {
4080d4081
<               Expression *e = new DotIdExp(loc, e1, Id::call);

Any thought?

------------------
 shinichiro.h

shinichiro.h wrote:
> Hi all,
> 
> I guess D syntax can allow implicit new expression like following:
> 
> class C {
>   this() {}
>   this(int x) {}
> }
> void func() {
>   C c = C();  // not new C()
>   c = C(3);   // not new C(3)
> }
> 
> I think the syntax is cute. And the syntax is not ambiguous and does
> not make DMD slower. I have succeeded to implement the syntax into

Well, it is ambiguous if the class contains a static opCall, but then again, I'd suggest that syntax instead of the current 'auto' storage modifier.

auto C c = new C();      // would become    C c = C();
// and
C c = new C();     // would stay the same


-- 
Tomasz Stachowiak  /+ a.k.a. h3r3tic +/

"Tom S" <h3r3tic@remove.mat.uni.torun.pl> wrote in message news:e5l5o1$1foc$1@digitaldaemon.com...
> shinichiro.h wrote:
>> Hi all,
>>
>> I guess D syntax can allow implicit new expression like following:
>>
>> class C {
>>   this() {}
>>   this(int x) {}
>> }
>> void func() {
>>   C c = C();  // not new C()
>>   c = C(3);   // not new C(3)
>> }
>>
>> I think the syntax is cute. And the syntax is not ambiguous and does not make DMD slower. I have succeeded to implement the syntax into
>
> Well, it is ambiguous if the class contains a static opCall, but then again, I'd suggest that syntax instead of the current 'auto' storage modifier.

I'll second that.  It seems like the nicest proposal so far to eliminate the multiple meanings of "auto".

-Craig

On Wed, 31 May 2006 23:10:58 -0500, Craig Black <cblack@ara.com> wrote:
> "Tom S" <h3r3tic@remove.mat.uni.torun.pl> wrote in message
> news:e5l5o1$1foc$1@digitaldaemon.com...
>> shinichiro.h wrote:
>>> Hi all,
>>>
>>> I guess D syntax can allow implicit new expression like following:
>>>
>>> class C {
>>>   this() {}
>>>   this(int x) {}
>>> }
>>> void func() {
>>>   C c = C();  // not new C()
>>>   c = C(3);   // not new C(3)
>>> }
>>>
>>> I think the syntax is cute. And the syntax is not ambiguous and does
>>> not make DMD slower. I have succeeded to implement the syntax into
>>
>> Well, it is ambiguous if the class contains a static opCall, but then
>> again, I'd suggest that syntax instead of the current 'auto' storage
>> modifier.
>
> I'll second that.  It seems like the nicest proposal so far to eliminate the
> multiple meanings of "auto".

Thirded.. in fact I seem to recall Walter expressed a liking for it, as the solution to the double meaning of "auto", but then I later read all these threads re-hashing "auto" again and again, with no-one mentioning this and I think maybe I imagined it.

Regan

> Well, it is ambiguous if the class contains a static opCall, but then again, I'd suggest that syntax instead of the current 'auto' storage modifier.

Oops! I missed the static opCall. Sorry.

------------------
 shinichiro.h

In article <20060601132500.408f82ef.hamaji@nii.ac.jp>, shinichiro.h says...
>
>> Well, it is ambiguous if the class contains a static opCall, but then again, I'd suggest that syntax instead of the current 'auto' storage modifier.
>
>Oops! I missed the static opCall. Sorry.
>
>------------------
> shinichiro.h

Some people have suggested to use a 'var' keyword as in Javascript or the
forthcoming C# 3.0 to express type inference.
auto c = new C ();
would become:
var c = new C ();

and there is no more ambiguity with the static opCall.
Personnaly I would have prefer a keyword like 'let' as in OCaml that as a strong
and inferred type system.