Bug 2945 – Precedence of 'new' vs '.'

In Java one can write: new MyClass().run(); in D this does not compile, parenthesis are needed. (new MyClass()).run(); I think this should behave like Java. See also http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=89433

There might be a problem here in that in D you can write it without the brackets: new MyClass.Foo; Is the above trying to create a new Myclass.Foo or is it trying to create a new MyClass and then access its Foo member? It depends on the type of Foo, and such a dependency is, I think, what Walter has been trying to avoid. Nevertheless, I often forget the brackets myself and wouldn't mind this change, I just think the above means that it's not going to happen.

(In reply to comment #1) > There might be a problem here in that in D you can write it without the > brackets: > > new MyClass.Foo; > > Is the above trying to create a new Myclass.Foo or is it trying to create a new > MyClass and then access its Foo member? It depends on the type of Foo, and such > a dependency is, I think, what Walter has been trying to avoid. > > Nevertheless, I often forget the brackets myself and wouldn't mind this change, > I just think the above means that it's not going to happen. > Ceraintly. However, new MyClass().Foo; has no such ambiguity until D becomes capable of returning types from functions. -- Simen

(In reply to comment #2) > Ceraintly. However, new MyClass().Foo; has no such ambiguity until D becomes > capable of returning types from functions. Traditionally, runtime reflection like that is done by calling methods on the returned type, not by using a compile-time operator. So it would look more like: MyClass.Foo.instantiate();

*** This issue has been marked as a duplicate of issue 8635 ***