Re: Error about @disabled constructor when there is a custom one

[Simen Kjaeraas]

On 2013-01-22, 19:45, Minas Mina wrote:

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

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?

You *are* using the default one. The one without parameters *is* the
default constructor, and you are calling the constructor without  
parameters.

One could argue that the compiler should choose the other constructor, and
even that having default constructors is reasonable. However, D has gone
the route of not having default constructors for structs. Instead,
structs are defined to be trivially constructible from T.init.

The workaround is to use static opCall:

struct Scene
{
        Array!Surface objects;
        Array!Light lights;
        
        /*private*/ BVHNode root;
        
        @disable this();
        
        this(size_t objectReserveSpace = 20, size_t lightReserveSpace = 3)
        {
                objects.reserve(objectReserveSpace);
                lights.reserve(lightReserveSpace);
        }

	static Scene opCall(size_t objectReserveSpace = 20, size_t  
lightReserveSpace = 3)
        {
                return Scene(objectReserveSpace, lightReserveSpace);
        }
}
--
Simen