On Tuesday, 28 August 2012 at 21:01:52 UTC, David Piepgrass wrote:
this this(this){} //postblitz?
This is not an appropriate syntax, not just because it looks
silly, but because a postblit constructor is not really a
constructor, it's is a postprocessing function that is called
after an already-constructed value is copied. So I don't think
there's any fundamental need for postblit constructors to look
like normal constructors.
I'm sure this case has an easy solution. How about:
struct Foo {
this new() { ... } // constructor
this() { ... } // postblit
}
But now you're breaking consistency by not including a return
type. maybe 'this this()' but that looks like a mistake or
typo.
I don't see how "this this()" is any worse than "this(this)";
IMO neither name really expresses the idea "function that is
called on a struct after its value is copied". But a postblit
constructor doesn't work like normal constructors, so keeping
the "this(this)" syntax makes sense to me even though it is
not consistent with normal constructors. "this()" has the
virtual of simplicity, but it's even less googlable than
"this(this)".
As long as it's an established standard it won't matter.
With his insistence that constructors have a return type, then
the postblit should too. Although keep in mind most likely you
won't 'return' anything in constructors and it's assumed that
'return this;' is entered at the very last line (although that
becomes a special case, and that makes it okay right?).
And for overload distinction (new vs load), which is an issue
beyond Memory Pools and effects and even larger codebase.
There needs to be a consistent way to distinguish (by name) a
constructor that loads from a file, and one that creates the
object "manually".
Isn't that more an API issue?
Sorry, I don't follow.
Having a named constructor compared to a default one. If there's
only one type of constructor (although different ways to call it)
then there shouldn't be an issue; Not really. But the problem was
down to 'is this a struct or a class' problem. Could do Hungarian
notation/prefixes; Then you're forced to know each time you use
it (unless you use auto everywhere).
struct MyStruct
becomes
struct Struct_MyStruct
or
struct S_MyStruct
Same problem, how do you tell it ahead of time without
completely rewriting the rules? leaving it as 'this' and
'~this' are simple to remember and work with, and factory
functions should be used to do a bulk of work when you don't
want the basic/bare minimum.
Sorry, I don't understand what you're getting it. I suspect
that you're interpreting his proposal in a completely different
way than I am, and then trying to expose the flaws in your
interpretation of the proposal, and then I can't follow it
because my interpretation doesn't have those flaws :)
But our own opinions never have flaws :)
Being able to name the constructor whatever you want although
may sound nice likely is more a hassle than it's worth. Like
namespace issues. I agree being able to override new could be
useful for types of allocation, but the way he presented it
suggested new was the constructor & allocator, meaning you'd have
to have in depth detail of both steps in order to override it
later. Abstraction then is thrown away and the black box method
becomes a white/clear box method, encapsulation goes out the
window.
Make everything as simple as possible, but not simpler. --
Albert Einstein
