I propose an idea, for discussion (robust discussion even better ;-)

Add an new attribute to class, named 'sealed'.

No, not sealed as in Scala.

No, not sealed as in C#

sealed as in oxford dictionary (close securely, non-porous).

when sealed is applied on the class, this means the class is sealed.

the sealed attribute only makes sense within a module, and affects nothing outside of the module.

When sealed is applied to the class, then, interfacing to a class within a module, from code outside that class - but still within the module, can now only occur via the published interface of the class.

outside code in the module, can no longer directly access your private parts!

The class is sealed.

On Thursday, 17 May 2018 at 02:32:07 UTC, KingJoffrey wrote:
> I propose an idea, for discussion (robust discussion even better ;-)  ....

oh, and it would be great, if the D 'elite' could way in to the discussion as well, as opposed to only waying in *after* a DIP is put forward.

All ideas would be helpful, including how complex it 'might' be to implement (compiler people).

Would it, or could it, break compatability - in any way..etc.etc...

Can you provide even one anecdote where this would have been useful and the workaround that has been suggested to you multiple times (putting the type in its own module) wouldn't have worked or would have caused other problems?

I mean, usually we need to do a cost/benefit analysis, and the first part of that, the one that people generally do instinctively, is try to describe the benefit. You seem to view the benefit as self-evident, but we've told you many times that it isn't self-evident to us, so you have more work to do if you want to convince anyone.

If you just want to vent, though, you might say that explicitly.

On Thursday, 17 May 2018 at 04:01:11 UTC, Neia Neutuladh wrote:
>
> If you just want to vent, though, you might say that explicitly.

This is hardly a great way to start the discussion.

When I said robust, I meant useful too.

On Thursday, 17 May 2018 at 04:01:11 UTC, Neia Neutuladh wrote:
> Can you provide even one anecdote where this would have been useful and the workaround that has been suggested to you multiple times (putting the type in its own module) wouldn't have worked or would have caused other problems?
>

My opening discussion outlines what I want, very very clearly.

The hack you mention, is not what I am asking for in my opening discussion.

Please go back and read my opening discussion properly.

On Thursday, 17 May 2018 at 04:01:11 UTC, Neia Neutuladh wrote:
> so you have more work to do if you want to convince anyone.

Again, a reminder, this is not a DIP. It's *just* a discussion.

The purpose of the discussion is not necessarly to convince anyone, of anything.

The purpose of the discussion is to gather peoples views, thoughts, ideas, concerns.....

On Thursday, 17 May 2018 at 04:01:11 UTC, Neia Neutuladh wrote:
>
> I mean, usually we need to do a cost/benefit analysis, ...

The benefit is explained in my opening discussion.

That is, i can have more than just a single class in a module file, as still be able to 'program to the interface' of the class, rather than implicitely give all other code in that module access to the private parts of my class.

Programming to the interface, is clear design philosophy of mine. Which is why I actually like the C++ friend attribute - because that is an explicit part of the defined interface.

An additional benefit is, that a class not marked as sealed (in a module), is a warning sign that anything else in the module (but outside of the class), may ignore the your class interface (i.e. can access it's private parts). So it could be helpful attribute for the way in which you approach analysing the code within the module.

For me, personally, I see this as a benefit. I do not see any downside (from a user perspective).

It does not change the benefit others get from having the status quo - which would remain unaffected - and while the status quo does indeed have benefits (as I've discovered in the other thread), it also has retains the downside of other local code in the module being able to bypass a declared interface.

If people want to propose putting each class in it's own module, that does not address my requirements, and therefore is not helpful to this discussion.

On Thursday, 17 May 2018 at 05:06:54 UTC, KingJoffrey wrote:
>
> If people want to propose putting each class in it's own module, that does not address my requirements, and therefore is not helpful to this discussion.

you could declare the public api of your class inside an actual interface then use it instead of the class, that wont give you access to the private members of the class.

On Thursday, 17 May 2018 at 06:03:19 UTC, arturg wrote:
>
> you could declare the public api of your class inside an actual interface then use it instead of the class, that wont give you access to the private members of the class.

you mean like this?

--------------------
module test;

interface Animal { string makeNoise(); }

class Dog : Animal
{
    private string noiseType = "woof";

    override string makeNoise()
    {
        return this.noiseType;
    }
}

void main()
{
    import std.stdio;

    auto dog = new Dog;
    dog.noiseType = "meow"; // grr!
    writeln(dog.makeNoise()); // wtf! Thanks to D, my dog can now meow!
}

--------------------

On Thursday, 17 May 2018 at 07:30:58 UTC, KingJoffrey wrote:
> On Thursday, 17 May 2018 at 06:03:19 UTC, arturg wrote:
>>
>> you could declare the public api of your class inside an actual interface then use it instead of the class, that wont give you access to the private members of the class.
>
> you mean like this?
>
> --------------------
> module test;
>
> interface Animal { string makeNoise(); }
>
> class Dog : Animal
> {
>     private string noiseType = "woof";
>
>     override string makeNoise()
>     {
>         return this.noiseType;
>     }
> }
>
> void main()
> {
>     import std.stdio;
>
>     auto dog = new Dog;
>     dog.noiseType = "meow"; // grr!
>     writeln(dog.makeNoise()); // wtf! Thanks to D, my dog can now meow!
> }
>
> --------------------

no, that uses type inferance.
you have to do
Animal dog = new Dog;