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
