Voldemort structs no longer work?

[H. S. Teoh]

On Sat, Dec 15, 2012 at 01:09:33PM -0800, Jonathan M Davis wrote:
> On Saturday, December 15, 2012 12:18:21 H. S. Teoh wrote:
> > It seems that the only clean way to do this is to use a class
> > instead of a struct, since the .init value will conveniently just be
> > null, thereby sidestepping the problem.
> 
> That would incur unnecessary overhead and probably break all kinds of
> code, because they're then reference types instead of value types, and
> a _lot_ of code doesn't use save propperly. If structs can't do what
> we need as Voldemort types, it's just better to make it so that
> they're not Voldemort types.  Voldemort types are a cute idea, and in
> principle are great, but I don't think that it's worth fighting to
> keep them if they have problems.
[...]

Well, the current way many Phobos ranges work, they're kind of
pseudo-Voldemort types (except they don't actually need/use the context
pointer):

	auto cycle(R)(R range) {
		struct CycleImpl {
			R r;
			this(R _r) { r = _r; }
			... // range methods
		}
		return CycleImpl(range);
	}

	auto r = cycle(myRange);

While it's true that you can write:

	typeof(cycle(myRange)) s;

and thereby break encapsulation, if someone is desperate enough to do
such things they probably have a good reason for it, and they should be
able to deal with the consequences too.

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?


T

-- 
It is impossible to make anything foolproof because fools are so ingenious. -- Sammy