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

Modules originate in ML.

Which do something very similar as they are not tied to files.

On Saturday, 12 February 2022 at 22:18:19 UTC, rikki cattermole wrote:
> Modules originate in ML.
>
> Which do something very similar as they are not tied to files.

That's interesting. I will look into that (ML).

btw. Do you think, that since D modules are 'tied to files', that 'inner modules concept' would be to difficult/complex to ever implement in D?

On 13/02/2022 11:23 AM, forkit wrote:
> On Saturday, 12 February 2022 at 22:18:19 UTC, rikki cattermole wrote:
>> Modules originate in ML.
>>
>> Which do something very similar as they are not tied to files.
> 
> That's interesting. I will look into that (ML).
> 
> btw. Do you think, that since D modules are 'tied to files', that 'inner modules concept' would be to difficult/complex to ever implement in D?

It would be a major refactoring to allow multiple modules per file.

It would have to be implemented as a separate thing in the compiler, I think.

On Saturday, 12 February 2022 at 22:26:58 UTC, rikki cattermole wrote:
> It would be a major refactoring to allow multiple modules per file.

the compiler already does it, to some extent, for mixins.

it should be easy to implement.

On 13/02/2022 11:30 AM, Adam D Ruppe wrote:
> On Saturday, 12 February 2022 at 22:26:58 UTC, rikki cattermole wrote:
>> It would be a major refactoring to allow multiple modules per file.
> 
> the compiler already does it, to some extent, for mixins.
> 
> it should be easy to implement.

I'm glad to be wrong, would be an interesting experiment if that is the case.

On Saturday, 12 February 2022 at 22:03:08 UTC, bachmeier wrote:
> ..
> My impression, which may be wrong, is that nobody's ever made a strong case
> that this issue is a sufficient problem to warrant yet another addition
> to an already large and growing language.

Oh. I'm not trying to make that case ;-)

Let's put 'the case' aside for now ;-)

I'm just exploring at 'a conceptual level', how to retain private visibility within a module without having to split it into 'separate files'.

Conceptually, nothing changes really.

You end up creating mulitple modules either way (whether in separate files, or within inner modules).

None of the language rules would change, with regards to modules, as I see it, (conceptually).

On Saturday, 12 February 2022 at 22:33:25 UTC, forkit wrote:
>
> I'm just exploring at 'a conceptual level', how to retain private visibility within a module without having to split it into 'separate files'.
>

Actually, there's more to it, that I'm looking for:

 - Stronger encapsulation within components, contained within a module.

 - Enscapsulating all the information needed within a module, within a single file.

It seems the only practical way to achieve the above, *without* changing language rules with regards to modules/visibility etc, is through an inner modules concept.

Again, conceptually only (I'm not making the case that D should actually do this).

On Saturday, 12 February 2022 at 22:51:58 UTC, forkit wrote:
>

As a demonstration:

.. the superpower of Rust's inner modules (even when using 'unsafe'):

// ---

#![allow(non_snake_case)] // damn those language designers!

fn main() {
    unsafe {
        innerModule::SIZE = 10; // compile time error -> static `SIZE` is private
    }
}

// Remember, private is default in Rust.
// So both this innerMod and the static var SIZE are both private.
//
mod innerModule {
    // annotate below pub to make it accessible outside this inner module.
    static mut SIZE: i32 = 5;
}

// -----

More very interesting analysis here:

https://iximiuz.com/en/posts/rust-privacy-and-visibility/