It shouldn't. It should just make it so that the struct it's in
has a @disabled init value as well - which is annoying in its
own right, but it's not as restrictive. Regardless, if you want
to guarantee that a struct is constructed rather than having
its init value used, you have no choice. Asserting like you
suggested could be done, but you'd have to put assertions in
every function but opAssign (if you declare it) that tested
whether the struct had been properly initialized or not, and
that's going to be at least somewhat error-prone. If @disabling
the init value is too restrictive though and you _can't_ use
the init value, then it could work.
Thanks for clarifying. RefCounted takes the assert approach and
clearly has a strong case for avoiding the restrictions. I tend
to think Database should avoid the restrictions as well.
Though actually, if you can't use the init value and can't
disable it, instead of asserting, you could always just set the
struct to the default that you want if it's not initialized.
That's a bit annoying, but it would be an option.
Yes, for this particular object, the cost is probably not an
issue and I should consider just initializing in every member
function (except opAssign).
Also, based on the name of your struct - Database - it sounds
like a handle for talking to the database, which is the sort of
thing that I'd expect to be very long lived and for which you
likely would only have a few actual objects allocated. And
since you're talking about reference-counting it, clearly, you
intend to put it on the heap. And if you're dealing with a
long-lived object on the heap where there won't be very many of
them, you might as well just use a class and avoid the whole
default-constructor issue (since classes have them). Using the
GC to allocate such objects is usually fine, and if it isn't,
std.allocator should make allocating them easy. Having them be
reference-counted would just increase their overhead, and what
you're doing clearly isn't interacting well with struct
semantics anyway, because you basically want to require that a
default constructor be used.
Yes your observations on the Database type are accurate. I'm
trying to generally avoid the GC in this library, but I think
that the non-deterministic class destruction in terms of the
timing and sequence is probably a deal breaker in general.
Also, I have at least one other object, Statement, that also
needs to be struct member compatible but that does not require
default construction, although all other objects come from
factories. In this case also, though, deterministic destruction
is critical. I agree also that there is the runtime cost (which
is mitigated perhaps by no collection) but it's fine for the
outer types. For inner types, like Row and Value, I'm currently
using proxies to avoid GC and RC.
RefCounted wouldn't be workable with this, for example.
It might not be. I don't know. I'd have to look at it.
Certainly, if it were, it wouldn't have an init value and would
have be explicitly initialized. But Walter and Andrei already
seem to have come to the conclusion that RefCounted isn't going
to cut it anyway (much as it comes close) and are looking at
adding a ref-counting mechanism to the language, in which case,
that's what you'd want to use rather than RefCounted for
ref-counted objects anyway. I have no idea when that will
actually be implemented though. Regardless, I'd suggest that
you seriously consider using a class instead like I suggested
above.
It will be interesting to see how that progresses.
erik
