Voldemort structs no longer work?

Jonathan M Davis jmdavisProg at gmx.com
Sat Dec 15 14:03:55 PST 2012


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


More information about the Digitalmars-d mailing list