More on C++ stack arrays

[Jonathan M Davis]

On Friday, October 25, 2013 00:06:52 deadalnix wrote:
> On Thursday, 24 October 2013 at 20:04:38 UTC, Jonathan M Davis
> 
> wrote:
> > On Thursday, October 24, 2013 21:07:16 deadalnix wrote:
> >> On Thursday, 24 October 2013 at 18:22:49 UTC, Jonathan M Davis
> >> 
> >> wrote:
> >> > Agreed. But there's a significant difference between @system
> >> > and illegal, and
> >> > deadalnix was claiming that such init values were illegal per
> >> > the language
> >> > spec, which is what I was objecting to.
> >> > 
> >> > - Jonathan M Davis
> >> 
> >> I never claimed that. I claimed that the init value, whatever
> >> it
> >> is, must be considered as valid. This is only loosly coupled
> >> with
> >> void as init value.
> > 
> > Then what do you mean by valid?
> 
> Code operating on the struct must handle that case. It is a valid
> state for the struct to be in.

As in all the functions will work on it without blowing up (e.g. segfault due 
to a null pointer)? That's definitely desirable, but it's definitely not 
required by the spec, and there are times that it can't be done without adding 
overhead to the struct in general.

For instance, SysTime.init will blow up on many of its function calls due to a 
null TimeZone. The only way that I could make that not blow up would be to put 
a lot of null checks in the code and then give the TimeZone a default value. 
The alternative is to do what I've done and make it so that you have to assign 
it a new value (or assign it a TimeZone) if you want to actually use it. 
Sometimes, that might be annoying, but no one has ever even reported it as a 
bug, and SysTime.init isn't a particularly useful value anyway, even if it had 
a valid TimeZone (since it's midnight January 1st, 1 A.D.). I could disable 
the init value, but that would make SysTime useless in a bunch of settings 
where it currently works just fine so long as you assign it a real value later.

I agree that ideally Foo.init wouldn't do things like segfault if you used it, 
but that's not really possible with all types, and IMHO not having an init is 
far worse than having a bad one in most cases, since there are so many things 
than need an init value but don't necessarily call any functions on it (e.g. 
allocating dynamic arrays). Regardless, the language spec makes no 
requirements that Foo.init do anything useful. It's basically just a default 
state that the compiler/runtime can assign to stuff when it needs a default 
value. It doesn't have to actually work, just be a consistent set of bits that
don't include any pointers or references which refer to invalid memory.

- Jonathan M Davis