null [re: spec#]

[Walter Bright]

Jonathan M Davis wrote:
> Well, if it's a default constructer which has to be nothrow and maybe pure or 
> nothing, I'll take the default constructor. Now, if there's a better way to 
> handle this which would result in full-blown, arbitrary default constructors, 
> then that would be better, but something is better than nothing.

I just hate to get into the complex, buggy quagmire C++ has with this.


> Another thought relates to the discussion of @disable on a struct's default 
> constructor to disable init. What if we allowed default constructors but 
> disabled init in the same way that we'd be doing with @disable? So, a struct 
> uses init if it has no default constructor, but if it has one, then you can't 
> use it where init would be required. Would that help fix things? It certainly 
> would make some sense given that when using a default constructor, you don't 
> really want init anyway. It could just be annoying with static arrays and the 
> like (though = void should make it possible to make that work I think, if you 
> really need to).

Actually, you do as init takes care of most of the initializations, and ensures 
the fields have predictable values before the ctor starts.