22-Jan-2013 22:45, Minas Mina пишет:
I have this structure:
struct Scene
{
Array!Surface objects; // objects in the scene
Array!Light lights; // lights in the scene
/*private*/ BVHNode root; // root node of the BVH tree
@disable this(); // disable the default constructor because space
needs to be reserved for objects and lights
this(size_t objectReserveSpace = 20, size_t lightReserveSpace = 3)
{
objects.reserve(objectReserveSpace);
lights.reserve(lightReserveSpace);
}
}
auto scene = Scene(); // error about @disabled constructor
That is the reason I dislike D's struct constructors as they currently
stand. Behold as the above is always rewritten to:
auto scene = Scene.init;
that is the same as
Scene scene;
And for Scene.init to work it has to have T.init for all of its members.
You've hit what I think is the design bug w.r.t. conflating 0-argument
constructor (including one with all default args) and T.init.
Short answer is: use static opCall instead. In the meantime let us all
pray some supreme gods so that 0-arg constructor support is introduced
later on. (because opCall doesn't have some powers of constructors such
as constructing const object)
Yes, the default constructor is @disabled BUT I am not using that one. I
want to use the other one - the custom constructor. I guess it signals
an error because it has those defaults parameters. But shouldn't the
compiler choose that one?
The official stance seems to be that the code shouldn't compile i.e.
accepts-invalid.
http://d.puremagic.com/issues/show_bug.cgi?id=3438
--
Dmitry Olshansky
