Inner Modules?

[H. S. Teoh]

On Sat, Feb 12, 2022 at 09:39:37PM +0000, Basile B. via Digitalmars-d wrote:
[...]
> No it's just that this topic comes back every 3 monthes.
> 
> You'll be said that D bases its system of visibility attribute on
> modules and that you'll have to live with that.
[...]

Do we really have to live with it?

Proof-of-concept:

--------
auto makeObj() {
	int x = 1;
	int y = 2;
	struct Result {
		int getX() { return x; }
		void setX(int newX) { x = (x >= 0) ? newX : 0; }
		int getY() { return y; }
	}
	return Result();
}

void main() {
	import std;
	auto obj = makeObj();
	writeln(obj.getX);
	obj.setX(3);
	writeln(obj.getX);
	writeln(obj.getY);
	writeln(obj.getX);
	//obj.x = 1;	//  Error: no property `x` for type `test.makeObj.Result`
}
--------

Et voila! Now there is no way for anybody except the methods of Result
to touch the values x and y. (And note that the struct has no state
except the hidden context pointer, so it essentially behaves like a
class.)

Now, I'm not saying this is necessarily a *good* solution. (It probably
opens up a whole slew of other problems. :-D)  But it *can* be done, if
you're really *that* desperate.

Me, I just live with module-private and a few extra files. It's not the
end of the world, there are ways of coping with it. And module-private
can be really a good thing in situations where C++ needs friends.


T

-- 
Let's call it an accidental feature. -- Larry Wall