resource structs and default constuction

[Erik Smith via Digitalmars-d]

> 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