On Saturday, December 15, 2012 13:44:13 H. S. Teoh wrote: > But anyway, thinking a bit more about the .init problem, couldn't we > just say that .init is not accessible outside the scope of the function > that defines the type, and therefore you cannot declare a variable of > that type (using typeof or whatever other workaround) without also > assigning it to an already-initialized instance of the type? > > This way, the type still has an .init, except that it's only accessible > inside the function itself. Or are there unintended consequences here?
That's pretty much how it is now. The problem is all of the stuff that requires .init. For instance, lots of template constraints and static if use .init to check stuff about a type. Not having an .init gets in the way of a lot of template metaprogramming. And sometimes, you have to have .init or some things are impossible. For instance, takeNone will attempt to return an empty range of the given type (something which some algorithms need, or they won't work), and if the range doesn't have init or slicing, then it's forced to return the result of takeExactly, which is then a different range type. For some stuff, that's fine, for other stuff, that renders it unusable. I think that the only place that that affects Phobos at the moment is that you lose an optimization path in one of find's overloads, but I've been in other situations where I've had to make a range empty without changing its type and popping all of the elements off was unacceptable, and Voldemort types make that impossible. We may be able to work around enough of the problems caused by a lack of a usable init property to be able to continue to use Voldemort types, but some issues can't be fixed with them (like that of takeNone), and until we do find a solution for even the problems that we can fix, the lack of an init property tends to be crippling for metaprogramming. - Jonathan M Davis
