On Mon, 19 Oct 2009 22:53:23 -0400, Brad Roberts <[email protected]>
wrote:
Robert Jacques wrote:
On Mon, 19 Oct 2009 18:45:01 -0400, dsimcha <[email protected]> wrote:
== Quote from Andrei Alexandrescu ([email protected])'s
article
I'm having a hard time justifying that you use
new X(args)
to create a class object, and
X(args)
to create a struct object. I wrote this:
============
The syntactic difference between the expression creating a @struct@
object---Test(@\meta{args}@)@---and the expression creating a @class@
object---\cc{new Test(}\meta{args}@)@---may be jarring at first. \dee
could have dropped the @new@ keyword entirely, but that @new@ reminds
the programmer that an object allocation (i.e., nontrivial work) takes
place.
===============
I'm unhappy about that explanation because the distinction is indeed
very weak. The constructor of a struct could also do unbounded amounts
of work, so what gives?
I hereby suggest we get rid of new for class object creation. What do
you guys think?
Andrei
Absolutely. I've thought this for a while but hesitated to bring it
up because I
felt it was a bikeshed issue. Now that I think of it, though, it
would have the
substantive benefit of making it easier to switch from structs to
classes if you
suddenly realize you need polymorphism, or from classes to structs if
you suddenly
realize you need value semantics. I really can't see any downside
other than the
loss of static opCall for classes, which doesn't have tons of good use
cases anyhow.
As structs mix static opCall and ctors, there's no reason classes can't.
Why do we still have static opcall? What role does it play that ctors
don't?
Well, when you want it to return something other than a new instance. The
only practical example I have is for singleton-types implemented using
static (TLS) variables. Also, there was a recent bug/regression with
regard to struct ctors vs opCall. Though I think it's been fixed.
