June 08, 2022

On Wednesday, 8 June 2022 at 09:38:24 UTC, Ola Fosheim Grøstad wrote:

>

On Wednesday, 8 June 2022 at 09:34:09 UTC, forkit wrote:

>

Walter has his firm view. I have mine.

Sure, your viewpoint would make sense for D3, but then there would be many such adjustments to make.

To make all those adjustments in D2 with no breaking change would @lead @to @a @mess.

Not in this case. I already proposed something that can work without providing attribute soup.

Just extend the private access modifier to allow an optional specifier such as class/struct.

https://forum.dlang.org/post/wmamhwkfdqgzaqndgaus@forum.dlang.org

Ex.

class Foo
{
  private int a; // private to module
  private class int b; // private to class
}
June 08, 2022

On Wednesday, 8 June 2022 at 09:38:24 UTC, Ola Fosheim Grøstad wrote:
but then there

>

would be many such adjustments to make.

To make all those adjustments in D2 with no breaking change would @lead @to @a @mess.

Will it be so troublesome if it is well encapsulation?

June 08, 2022
On Wednesday, 8 June 2022 at 09:38:24 UTC, Ola Fosheim Grøstad wrote:
> On Wednesday, 8 June 2022 at 09:34:09 UTC, forkit wrote:
>> Walter has his firm view. I have mine.
>
> Sure, your viewpoint would make sense for D3, but then there would be many such adjustments to make.
>
> To make all those adjustments in D2 with no breaking change would @lead @to @a @mess.

I still don't get it.

I'm not advocating for my 'perfect world view' for D.

just: private(this)

That is not a breaking change. It would purely opt-in. Everyone gets what they want (except those who don't want any change).
June 08, 2022

On Wednesday, 8 June 2022 at 09:55:00 UTC, bauss wrote:

>

On Wednesday, 8 June 2022 at 09:38:24 UTC, Ola Fosheim Grøstad wrote:

>

On Wednesday, 8 June 2022 at 09:34:09 UTC, forkit wrote:

>

Walter has his firm view. I have mine.

Sure, your viewpoint would make sense for D3, but then there would be many such adjustments to make.

To make all those adjustments in D2 with no breaking change would @lead @to @a @mess.

Not in this case. I already proposed something that can work without providing attribute soup.

Just extend the private access modifier to allow an optional specifier such as class/struct.

https://forum.dlang.org/post/wmamhwkfdqgzaqndgaus@forum.dlang.org

Ex.

class Foo
{
  private int a; // private to module
  private class int b; // private to class
}

Could also be like this instead:

class Foo
{
  private int a; // private to module
  private this int b; // private to class
}

Thinking about it using this instead of class/struct is probably better, since it doesn't make sense to restrict to anything else other than itself.

June 08, 2022

On Wednesday, 8 June 2022 at 09:55:00 UTC, bauss wrote:

>
class Foo
{
  private int a; // private to module
  private class int b; // private to class
}

Right,No damage at all!

June 08, 2022
On Wednesday, 8 June 2022 at 09:57:49 UTC, forkit wrote:
> On Wednesday, 8 June 2022 at 09:38:24 UTC, Ola Fosheim Grøstad wrote:
>> On Wednesday, 8 June 2022 at 09:34:09 UTC, forkit wrote:
>>> Walter has his firm view. I have mine.
>>
>> Sure, your viewpoint would make sense for D3, but then there would be many such adjustments to make.
>>
>> To make all those adjustments in D2 with no breaking change would @lead @to @a @mess.
>
> I still don't get it.
>
> I'm not advocating for my 'perfect world view' for D.
>
> just: private(this)
>
> That is not a breaking change. It would purely opt-in. Everyone gets what they want (except those who don't want any change).

I completely agree. I really hate the current design, because I have been in situations where I have separated classes because they needed private fields, but then later I actually needed some of the fields shared and had to share those fields public.

So either you have to share all fields as friends or you share none.

It's too black/white.
June 08, 2022

On Wednesday, 8 June 2022 at 09:55:00 UTC, bauss wrote:

>

Just extend the private access modifier to allow an optional specifier such as class/struct.

I guess this is where ideas about aesthetics, consistency and usability differ. My view is that all of the proposed syntaxes are bad and would be confusing to people coming to the language. All proposal signal that something went wrong and somebody patched it up with band-aid and duct-tape.

And you still get one more case to deal with if you want to reason about this in meta programming.

June 08, 2022

On Wednesday, 8 June 2022 at 10:00:37 UTC, Ola Fosheim Grøstad wrote:

>

My view is that all of the proposed syntaxes are bad and would be confusing to people coming to the language.

But so is the current behavior to people that come to the language.

I see people asking every other week about why something isn't "private".

I think a lot of other people can testify to that too.

The solutions where at least allow one to opt-out of something, it's completely optional and it won't confuse anyone who don't use it.

In fact it might make it more understandable since you will realize that what you thought was private wasn't really private and that if you want it private to something then you specify "this".

It's much better than the current system where you have to move your classes to a new module, because then you lose all friend capabilities.

In some cases you might want both and D does not give you that.

You have to pick either friends only or privates only.

June 08, 2022
On Wednesday, 8 June 2022 at 07:54:11 UTC, Max Samukha wrote:
> On Wednesday, 8 June 2022 at 07:14:32 UTC, forkit wrote:
>
>>
>> Is that even a language? ;-)
>
> Haskell is The Language!

Well if Haskell can do it, why can't D?

"..and we can make fields private if we want. "

https://mmhaskell.com/blog/2019/1/7/why-haskell-i-simple-data-types

June 08, 2022

On Wednesday, 8 June 2022 at 10:20:37 UTC, bauss wrote:

>

On Wednesday, 8 June 2022 at 10:00:37 UTC, Ola Fosheim Grøstad wrote:

>

My view is that all of the proposed syntaxes are bad and would be confusing to people coming to the language.

But so is the current behavior to people that come to the language.

I see people asking every other week about why something isn't "private".

They would also ask what "private class" means. If you are gonna do it, do at least propose a proper keyword for it: local, hidden, internal…

Anything simple is better than @keyword, private(this), private class etc. Such syntax screams "amateur project" and I wouldn't even consider downloading a language like that. When I first tried D it was because the syntax looked clean (way before the @madness caught on).