http://d.puremagic.com/issues/show_bug.cgi?id=9372
Jacob Carlborg <doob@me.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |doob@me.com
--- Comment #1 from Jacob Carlborg <doob@me.com> 2013-01-22 23:34:19 PST ---
I don't know if this makes any sense but:
When the code "new Room" is run the runtime will first create a new instance of "Room" and initialize all fields. It will then run the constructor. Technically you don't need to run the constructor at all, I don't do that in my serialization library. The field "t" cannot be initialized because it has its default constructor disabled. I'm not sure if the default constructor of Trouble is the same as "Trouble.init". If not, I think this should compile. If it is the same, then this error perhaps makes sense.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=9372
--- Comment #2 from hsteoh@quickfur.ath.cx 2013-01-23 07:52:50 PST ---
(In reply to comment #1)
Maybe it makes sense on some level, perhaps from the implementation POV, but to me, a language-level user, it makes no sense at all, because a ctor is supposed to be what initializes the class instance.
Furthermore, a class with a ctor that takes more than zero parameters causes "auto x = new Class;" to be rejected, because the ctor cannot be called with no arguments. So to me, this indicates that the ctor will always be called (as expected); the compiler never says "OK you called new with no parameters, I'll just default-initialize all your class fields". Since this is the case, it makes no sense to now suddenly require that all fields be default-initializable. It has always been the ctor's job to initialize all fields.
(In fact that's why I chose to use a class instead of a struct, since structs can be declared without calling any ctors.)
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=9372
--- Comment #4 from Jacob Carlborg <doob@me.com> 2013-01-23 08:02:58 PST ---
(In reply to comment #3)
> P.S. Even Object.factory does not allow the creation of objects without a default ctor, so I'd argue that in no case should the implementation require that all class fields be default-initializable when there's already a ctor to do the job.
Then that will break a lot of the safety D provides with its default initialized variables. Example:
class Foo
{
int a; // assume this is not initialized
this ()
{
writeln(a); // writes garbage
}
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=9372
--- Comment #5 from hsteoh@quickfur.ath.cx 2013-01-23 08:14:47 PST ---
It should be illegal to reference an uninitialized variable in the ctor. Something similar to how immutable fields are handled can be applied here: you're not allowed to read the value of an immutable field until it's initialized, and it can only be written to once.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=9372
--- Comment #6 from Jacob Carlborg <doob@me.com> 2013-01-23 11:57:38 PST ---
(In reply to comment #5)
> It should be illegal to reference an uninitialized variable in the ctor. Something similar to how immutable fields are handled can be applied here: you're not allowed to read the value of an immutable field until it's initialized, and it can only be written to once.
The following code with compiles DMD 2.061 and when it runs it prints "0".
import std.stdio;
class Foo
{
immutable int a;
this ()
{
writeln(a);
a = 3;
}
}
void main ()
{
new Foo;
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------