It already works if you use parens:
assert((new C(2)).x == 2);
I don't know if making it work without parens is a good idea or not, since I really don't know that the side effects of that would be.
Comment #3 by bearophile_hugs — 2012-09-09T17:49:31Z
(In reply to comment #2)
> I don't know if making it work without parens is a good idea or not, since I
> really don't know that the side effects of that would be.
I agree. If the side effects are bad, this bug report will be closed and future similar ideas will be marked as duplicates of this :-)
Comment #4 by timon.gehr — 2012-09-09T18:08:59Z
There are no side effects. This just lifts a trivial restriction.
Comment #5 by alex — 2012-09-09T18:26:32Z
Also, it's how C# (and probably Java too) does it.
Comment #6 by issues.dlang — 2012-09-09T18:31:47Z
I have absolutely no problem with this as long as there are no side effects. I just had figured that there was a valid reason why the parens were required. It's often the case that something will seem like it should work and doesn't but has a very good reason for why it doesn't, even if it looks fine at first glance.
> Also, it's how C# (and probably Java too) does it.
Given D's increased complexity, it wouldn't surprise me at all if D couldn't do it when they could, but if it can, it definitely should as well. I think that it's the syntax that pretty much everyone tries at first - only to find that it doesn't work.
Comment #7 by timon.gehr — 2012-09-09T18:40:01Z
(In reply to comment #6)
> I have absolutely no problem with this as long as there are no side effects. I
> just had figured that there was a valid reason why the parens were required.
> ...
Presumably it is just a C++ism that got carried over for no reason.
> Given D's increased complexity,
The D grammar is not particularly complex. (it is still somewhat more complex than it would need to be though.)
Comment #8 by andrej.mitrovich — 2012-12-08T15:10:55Z
*** Issue 8116 has been marked as a duplicate of this issue. ***
Comment #9 by yebblies — 2013-01-07T17:08:11Z
*** Issue 8826 has been marked as a duplicate of this issue. ***
Comment #10 by andrej.mitrovich — 2013-01-11T19:44:07Z
Added D1 to mark Issue 2945 a duplicate.
Comment #11 by andrej.mitrovich — 2013-01-11T19:44:14Z
*** Issue 2945 has been marked as a duplicate of this issue. ***
Comment #12 by bugzilla — 2013-01-19T11:37:42Z
D1 isn't going to get enhancements.
Comment #13 by bugzilla — 2013-01-19T11:42:36Z
This seems more of a "why do this" rather than "why not" ? Is C# doing it really a compelling case?
Comment #14 by bearophile_hugs — 2013-01-19T12:20:48Z
(In reply to comment #13)
> Is C# doing it really a compelling case?
Generally C# is a well designed languages. But in this case it's not a matter of copying C#.
In D I often have had to write:
(new Foo()).bar()
But that's not nice, because in D you are used to use UFCS:
new Foo().bar()
So it's not a big thing, but (unless it clashes with something else I am unaware of) it's a nice little improvement to have.
Comment #15 by timon.gehr — 2013-01-19T18:42:48Z
(In reply to comment #13)
> This seems more of a "why do this" rather than "why not" ?
In my opinion it is exactly the other way round. The "why not" question people actually ask. Note that this has been requested independently at least 5 times, and it has come up a few times on D.learn as well IIRC.
It lifts an arbitrary restriction and is very cheap. (Move a few lines of parser code somewhere else.)
> Is C# doing it really a compelling case?
No. But I do not think C# programmers ask "why do this".
Comment #16 by bearophile_hugs — 2013-02-08T16:27:38Z
An even better syntax is to allow new to act as a static method, that allows a fully UFCS syntax:
class Foo {
void bar() {}
}
Foo().new.bar();
Foo f = Foo.new;
Comment #17 by verylonglogin.reg — 2013-02-22T00:39:49Z
`c.new N().foo();` is already a valid syntex as Kenji Hara mentioned in pull discussion so I don't see any reasons to not merge implementing pull as current situation doesn't look consistent.
Comment #18 by github-bugzilla — 2013-06-08T19:57:41Z