On Thursday, 23 June 2022 at 11:10:58 UTC, The Zealot wrote:
>
> So instead of just implementing it yourself, you had others do your work, and now you won't even go and write the DIP you were gathering opinions for. Good job....

At no point did I agree to write a DIP.

In fact, I'm pretty sure I said the opposite, many times.

Also, I do not even the slightest technical skills or knowledge to even begin to think about how this would be implemented.

I write .NET GUI apps in C# for christ sake ;-)

I certainly never expected anyone to actually have the balls (or otherwise) to just go do it .. that was an unexpected bonus ;-)

On Thursday, 23 June 2022 at 11:16:39 UTC, forkit wrote:
>

look ma...

// ----
module test;
@safe:

import std;

class Base
{
    private(this) int x = 100;
    private int y = 200;
}

class Derived : Base
{
    //public int x = 200;
}

void main()
{
    Derived d = new Derived();
    writeln(d.x);
    writeln(d.y);
}
// ------


> dmdnew -preview=privateThis privatethis.d privatethis.d(21): Error: no property `x` for type `test.Derived`

woohoo! 6 years in the making!!!

(just to do what I've able to do for 20+ years in other languages).

On Thursday, 23 June 2022 at 11:21:41 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 23 June 2022 at 11:16:39 UTC, forkit wrote:
>> I certainly never expected anyone to actually have the balls (or otherwise) to just go do it .. that was an unexpected bonus ;-)
>
> But you got what you wanted then, so now we can put this issue on the back-burner ;)

yes. I'm done ;-)

On Thursday, 23 June 2022 at 11:04:40 UTC, forkit wrote:

> Well, my task, was to highlight this issue in D, and stop it from always being stuffed under the rug by the 'opposers'.

It was never "under the rug", as it popped up now and then by newbies.

If anything, you managed to change my opinion from "I don't need it, but who cares" to "It would be a failure to add it".
I would oppose any such DIP and hope Daniels branch won't make it in the mainstream.

"restricted" (or hidden/sees which I still think would be better names) would be a different thing, as this provides something new (preventing member functions from accessing specific fields). And fixes to the invariant handling are of course a good thing.

On Thursday, 23 June 2022 at 11:24:36 UTC, Dom Disc wrote:
>
> It was never "under the rug", as it popped up now and then by newbies.
>
> If anything, you managed to change my opinion from "I don't need it, but who cares" to "It would be a failure to add it".
> I would oppose any such DIP and hope Daniels branch won't make it in the mainstream.
>
> "restricted" (or hidden/sees which I still think would be better names) would be a different thing, as this provides something new (preventing member functions from accessing specific fields). And fixes to the invariant handling are of course a good thing.

Just when I thought I was out, they pull me back in!

On Thursday, 23 June 2022 at 10:55:29 UTC, Alexandru Ermicioi wrote:

> Imho package.d is not a kludge. Such approach is taken in typescript/javascript for example.

It is useful when you need to split a module into multiple submodules for other reasons than class-level encapsulation. In Javascript, there had been the '_' naming convention until it acquired proper class-level private https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes/Private_class_fields. Typescript has class-level private https://www.typescriptlang.org/docs/handbook/2/classes.html#private

On Thursday, 23 June 2022 at 11:54:26 UTC, Dennis wrote:
>
> Note that I don't actually want the feature myself, but I was curious how complex it would actually be to implement, and wanted to show that the discussion does not have to be a harsh conflict between two self-interested camps. Maybe when there's something concrete on the table we can all stop bickering over principles, definitions, quotes from authority figures etc. and get some real world experience. And when it gets rejected, at least you can still forkit ;)

They keep pulling me back in!!

But yes. So it seems we both wanted **exactly** the same thing.

Not some drawn out process where everyone will complain about this and that... but something one can start writing code with, and see what happens from there.

Thanks for you reffort, whether you like the idea or not ;-)

> I did NOT want to show that making noise on the forum is the way to get your feature in. Please don't keep bringing up the same points over and over, especially in other threads like [this one](https://forum.dlang.org/post/jjxxvzaehgzzwucapmap@forum.dlang.org).

This actually was never about making noise to 'get the feature in', but making noise to discover what people think about the idea, which is very interesting in itself.

The feature, even if it got into D, would not change my perspective on D, just based on that one feature. I still think other languages much better understand the concept of a user-defined type, than D, whose user-defined type outsources its own destiny, to the module! That is a complete joke to me. And always will be.

Mmm...I'm not sure why you're picking on my post there, since it was clearly in response to another idea.. but hey...

In any case, I reserve the right to bring up the point, or any point, whenever, and whereever I think it is appropriate.

On Thursday, 23 June 2022 at 21:32:14 UTC, forkit wrote:
> In any case, I reserve the right to bring up the point, or any point, whenever, and whereever I think it is appropriate.

All power to you. I reserve the right to bring up any issues with the manner in which points are being made.

You may retort.. I know you will ;-)