Bypassing the postblit?

[Ritu]

> There's no state. Just that it's an area in which Walter is 
> opened to a language change. Kenji is opposed though.
>
> Andrei


Greetings

I thank Andrei for spending some time on this thread and for 
informing that he and Walter are actively considering extensions 
to the postblit behavior. I take this opportunity to present a 
detailed use case of ours.

We have been working on implementing a Domain Specific Embedded 
Language in D. As is true with most other DSLs, the end users 
would be domain experts and not necessarily expert programmers. 
In our case the DSL we are creating would be useful for modeling 
systems in a specific domain.

I will try to create a small use case here. We want to provide 
our users with a construct called Fifo. A Fifo would be useful to 
enable data exchange between different blocks of the system being 
modeled. Typically a Fifo will allow different agents in the 
system to push or pull data. Additionally we want to enable 
following capabilities with a Fifo construct:

a/ Ability to declare an array (even multidimensional array) or 
Fifo's.
b/ Ability to pass a Fifo to a function argument. Also ability to 
pass an array of Fifos as an argument.
c/ Ability to pass a Fifo to std functions like writeln. In such 
a scenario, the element on the top of the Fifo gets printed.

Let us consider different aspects of providing the Fifo construct:

1. Fifo should be a Struct (not a Class)

A class instance necessarily needs to be initialized. With a 
struct we have possibility of lazy initialization.

2. Fifo initialization

As some forumites have suggested, one option is to force 
initialization at the time of declaration. I do not think this is 
a good option as far as a DSL is concerned. First of all there is 
no way in D (at least I am not aware) to disallow the default 
constructor (the init value must exist). Even for a class object, 
there is no way to keep the end-user away from trying to use null 
objects. Secondly, forcing initialization right at the time of 
declaration might require lots of boiler-plate code. While 
patterns like static opcall initialization may be good for 
programmers, these are not intuitive for the purpose of a DSL. 
Besides consider the amount of boilerplate code required for 
initializing all the Fifos in a 3 dimensional array of Fifos 
(requirement (a) in the list above).

3. Lazy Initialization

Given that explicit initialization may not be good enough, we 
consider lazy initialization. It mostly works, but does not fully 
satisfy requirement (b). An uninitialized Fifo when passed as a 
function argument exhibits totally unexpected behavior.

4. Forcing Fifo argument to be passed as a ref

This may be too difficult to explain to the end-user. To force it 
we may be required to disable the postblit (thereby disabling the 
copy constructor). But when we do that, a lot of other unexpected 
issues come up. For example the std.stdio.writeln expects 
copyable arguments. If we disable postblit, it becomes impossible 
to print the object using writeln (see requirement (c)).


With all these considerations, we need our Fifo to either:

(I) Get implicitly initialized at the time of declaration. This 
will require user-defined default constructor. We understand that 
this is not possible in D. We also understand that this is a 
small sacrifice we make to enable a lot of meta-programming at 
compile time.

OR

(II) Allow postblit to take care of uninitialized lazy Fifo 
instances. For this only we are asking for the ability to access 
and modify the source Fifo instance as well as the copied 
instance in the postblit.

Thanks for bearing with my long rant. As far as I can make out 
neither DIP49 nor DIP53 directly addresses this issue. Let me 
know if I have overlooked some aspects of these DIPs. I and my 
colleague at work are ready to spend time on creating a DIP for 
my use case. I believe it will also be useful for a couple of 
other usecases as well.

Regards
- Ritu