And a postblits would end up being...? The extra 'this' makes
it look like an obvious typo or a minor headache.
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)".
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.
If we take your approach and suggestion, which one should the
compile assume?
Something globalSomething;
class Something {
this defaultConstructor();
this duplicate(); //or clone
this copyGlobalSomething();
this constructorWithDefault(int x = 100);
}
By signature alone... Which one? They are all legal, they are
uniquely named, and they are all equal candidates. Order of
functions are irrelevant.
It could work identically to how D functions today. A 'new()'
constructor would be part of the root Object classes are
derived of, and structs would have an implicit 'new()'
constructor.
But new wouldn't be a constructor then would it? It would
still be based on allocating memory that's optionally
different. Constructor and allocation are two different steps;
And for it to seamlessly go from one to another defaults to
having a set default constructor. Let's assume...
class Object {
this new() {
//allocate
return defaultConstructor();
}
this defaultConstructor() {}
}
Now in order to make a constructor (and then destructor) you
either can:
A) overload or use 'defaultConstructor', which would be
publicly known
B) overload new to do allocation the same way and call a
different constructor and specifically add a destructor to make
sure it follows the same lines.
C) overload new to call the default allocator and then call a
different constructor
Now assuming you can make a different constructor by name, you
then have to be able to specify a destuctor the same way for
consistancy.
class CustomType {
this MyAwesomeConstuctor();
void MyAwesomeDestructor();
}
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 :)
