What is the case against a struct post-blit default constructor?

[Jonathan M Davis]

On Wednesday, October 10, 2012 21:11:29 foobar wrote:
> Arrays - without changing existing syntax we can use these
> semantics:
> 
> auto a = new int[](5); // compiler calls T() for each instance
> int[12] b; // ditto

And what on earth does that buy you over init? That's what init _does_. And 
since the value needs to be known at compile time (otherwise arrays won't work 
for directly initializing _anything_ that needs to be initialized at compile 
time), a constructor really doesn't buy you anything here at all. init 
provides a nice, consistent way of initializing or assigning a value to a 
variable as well as providing a consistent default state for a type when you 
need to be able to set a variable of that type to a consistent, safe state 
(e.g. with std.algorithm.move). And as built-in types don't _have_ 
constructors, there's no other way for generic code to generically initialize 
anything.

> I don't get this example. If foo throws than the calling code
> will get control. How would you ever get to read that garbage in
> aa[5]? The surrounding try catch block should take care of this
> explicitly anyway.
> 
> E.g.
> try {
> aa[5] = foo(); // foo throws
> // ## do something with aa[5], this won't happen
> } catch {
> // Please handle aa[5] here explicitly.
> //
> }
> // @@ do something with aa[5], works due to the explicit fix in
> the catch.

It's a compiler (druntime?) bug. T.init is inserted at aa[5] regardless of 
whether foo() returns or not. It's just the assigned to the correct result of 
foo succeeds. So, if an exception is thrown, you end up with a value at aa[5] 
when you're not supposed to:

http://d.puremagic.com/issues/show_bug.cgi?id=3825

The fact that we have init saves us from it being set to garbage. In general, 
having init saves us from garbage where someone screws up, making behavior 
deterministic and therefore more easily caught, debugged, and fixed. It also 
saves us from the compiler complaining about stuff not being initialized when 
it really was like Java does.

> Isn't @disable breaks those algorithms in phobos anyway?

Which is why @disable is kind of a sucky idea. But as long as init exists for 
a type, functions such as std.algorithm.move can use it. Without it, they're 
pretty much screwed. So, using @disable will restrict what you can do with a 
type, but it least sane types can take advantage of such functions. Without 
init, _none_ could, or if they did, it would be unsafe.

> To answer the above question, I'd say there's nothing wrong with
> init to void. This is what happens anyway since the .init isn't
> used and the optimizer will optimize it away.

Using void is dangerous and should be avoided unless absolutely necessary, 
otherwise you run a high risk of ending up with garbage values, giving you 
non-determinstic behavior, which tends to lead to very nasty, hard-to-find 
bugs.

> Again, thanks for the explanation. I have to say that on a
> general level I have to agree with Don's post and I don't see how
> the .init idiom generally "works" or is useful. I can't see
> anything in the above examples that shows that .init is
> absolutely required and we can't live without it. The only thing
> that worries me here is the reliance of the runtime/phobos on
> .init.

init avoids all kind of initialization problems and is an absolute godsend for 
generic code - so much so that letting it be used for compile time reflection 
and type inferrence even when disabled (though it still couldn't be used in 
actual code) is under discussion. It would actually be pretty bad not to have 
init (which is why @disable sucks). I, for one, am _very_ glad that we have 
init. I'm guessing that you haven't written much generic code in D if you 
think that init should go away. You pretty much _need_ something like init for 
a lot of the stuff that you have to do in template constraints and whatnot.

D's use of init is far superior to either C++ or Java's approach IMHO. But 
regardless of its various pros or cons, it's here to stay.

- Jonathan M Davis