Do you mean something like this?struct Foo { @disable this(); this(int) {} } void main() { // Foo f1; // Error auto f2 = Foo(1); }
Thanks Beorophile. I somehow overlooked @disable for default constructor. But I hope that you get the larger picture. Imagine an end-user wanting to create an array of Fifos. In a DSL, it does not come out nice if you ask him to initialize all the Fifo elements.
My rant boils down to this. To have the ability to create "native like" data in any DSL embedded in D, we need one of the following three:
1. The ability to have a user-defined default constructor for structs. I believe this is not possible since it does not go well with D's metaprogramming. 2. Some sort of preblit. That also is not possible since it boils down to having a default constructor. 3. Allowing postblit to access and modify both the source and target struct instances in a postblit.
The last two of these options rely on lazy initialization which works fine except for the situation wherein you pass an uninitialized struct instance to a function. Also I believe "lazy initialization" is a pattern used often in D containers. And the postblit enhancement I am asking for helps take care of the unexpected behavior that shows up with those container classes too.
Regards - Ritu
