June 09, 2022
private(scope)

Nice and simple, if you know what private and scope does, you can probably guess what it does here.
June 09, 2022
On Thursday, 9 June 2022 at 05:52:10 UTC, rikki cattermole wrote:
> private(scope)
>
> Nice and simple, if you know what private and scope does, you can probably guess what it does here.

It's just those brackets that bother me. Something doesn't seem right with them there like that. Consider where else in the language () is used, for example.

btw.

In swift (where they seem to have actually thought this out sensibly):

'fileprivate' -> means an entity that is accessible anywhere in that file.

'private' -> means an entity that cannot be accessed anywhere except for the enclosing type, such as a class

so here's yet another idea: - just an idea, not a proposal ;-)

private -> no change. means an entity that is accessible anywhere in that file.

scopeprivate -> means an entity that cannot be accessed anywhere except for the enclosing type, such as a class

June 09, 2022
On Thursday, 9 June 2022 at 06:21:08 UTC, forkit wrote:
>

another example, where I think swift done it better:

i.e. you know exactly what the designers intentions were when this was written.

(in Swift 4, an class extension can now access a private member)

-- some file --
class A { private var name = "First Letter" }

extension A
{
  func printName()
 {
   print(name) // you may access it here from swift 4. Swift 3 will throw error.
 }
}
-- end file --

June 09, 2022
On Thursday, 9 June 2022 at 06:21:08 UTC, forkit wrote:
> On Thursday, 9 June 2022 at 05:52:10 UTC, rikki cattermole wrote:
>> private(scope)
>>
>> Nice and simple, if you know what private and scope does, you can probably guess what it does here.
>
> It's just those brackets that bother me. Something doesn't seem right with them there like that. Consider where else in the language () is used, for example.
>
> btw.
>
> In swift (where they seem to have actually thought this out sensibly):
>
> 'fileprivate' -> means an entity that is accessible anywhere in that file.
>
> 'private' -> means an entity that cannot be accessed anywhere except for the enclosing type, such as a class
>
> so here's yet another idea: - just an idea, not a proposal ;-)
>
> private -> no change. means an entity that is accessible anywhere in that file.
>
> scopeprivate -> means an entity that cannot be accessed anywhere except for the enclosing type, such as a class

Couldn't it be `private scope` or `scope private` then if the brackets bother you?

I think scopeprivate as a keyword is really long. Maybe it could just be `scope` and nothing else, since `scope` as it is now cannot be used in the same context and thus it won't conflict with how it currently is.

But perhaps it's better to have `hidden` then anyway since it's much more clear.
June 09, 2022

On Thursday, 9 June 2022 at 09:47:54 UTC, bauss wrote:

>

But perhaps it's better to have hidden then anyway since it's much more clear.

You might as well, adding a new protection level might be a breaking change thanks to meta-programming.

It is probably possible to write the parser in such a way that "hidden" isn't a keyword. At worst it will impact people who use a type called "hidden".

June 09, 2022

On Thursday, 9 June 2022 at 10:16:06 UTC, Ola Fosheim Grøstad wrote:

>

On Thursday, 9 June 2022 at 09:47:54 UTC, bauss wrote:

>

But perhaps it's better to have hidden then anyway since it's much more clear.

You might as well, adding a new protection level might be a breaking change thanks to meta-programming.

It is probably possible to write the parser in such a way that "hidden" isn't a keyword. At worst it will impact people who use a type called "hidden".

Could make it an error when used directly, but a warning when accessed through traits.

Then deprecate it over time, allowing people to fix their code to support it.

June 09, 2022
On Wednesday, 8 June 2022 at 20:35:30 UTC, Walter Bright wrote:
> On 6/8/2022 1:23 AM, Max Samukha wrote:
>> Why is it less of an abomination?
>
> Because "friend" classes are a mess. They can be spread all over your code.
>
> Modules are physically co-located in the same file, making them easy to manage.

To me, mandating a certain codebase structure is not an advantage. Also, you can always misuse 'package' to make a mess out of a D codebase.

'friend' is abominable for a different reason - it breaks encapsulation by exposing the entire state instead of selected members, and D is no different in this respect.
June 09, 2022

On Thursday, 9 June 2022 at 13:05:46 UTC, Max Samukha wrote:

>

'friend' is abominable for a different reason - it breaks encapsulation by exposing the entire state instead of selected members, and D is no different in this respect.

Not necessarily. You can put all the members you want to expose in a separate C++ class inside the other class and only expose this one.

You usually don't want to make another class a friend, just some specified functions.

The tools for improved encapsulation are there even if most C++ programmers don't care enough to use them.

And I guess that also is the situation for D, most D users care more about convenience than strictness. You see this in D code bases by the tendency to «abuse» string mixins!

At the end of the day, culture has a massive impact…

June 09, 2022
On Thursday, 9 June 2022 at 13:15:14 UTC, Ola Fosheim Grøstad wrote:
>
> And I guess that also is the situation for D, most D users care more about convenience than strictness...

I think this is true, particulary for 'core'.

I think this is why private is considered as a restrictive move, instead of an enhancement ;-)

But whatever....

I'm going to spend some time on Swift now (having never used it before).

It looks really interesting - and already has proper access modifiers ;-)

It also has what initially attracted me to D too (which was the convenience of using arrays with the [..] magic.

This too looks interesting:

// array of any items
let anything: [Any] = [1, "a", 3.14]

https://theswiftdev.com/beginners-guide-to-swift-arrays/
June 10, 2022

On Thursday, 9 June 2022 at 21:44:51 UTC, forkit wrote:

>

On Thursday, 9 June 2022 at 13:15:14 UTC, Ola Fosheim Grøstad wrote:

>

And I guess that also is the situation for D, most D users care more about convenience than strictness...

I think this is true, particulary for 'core'.

I think this is why private is considered as a restrictive move, instead of an enhancement ;-)

But whatever....

I'm going to spend some time on Swift now (having never used it before).

It looks really interesting - and already has proper access modifiers ;-)

It also has what initially attracted me to D too (which was the convenience of using arrays with the [..] magic.

This too looks interesting:

// array of any items
let anything: [Any] = [1, "a", 3.14]

https://theswiftdev.com/beginners-guide-to-swift-arrays/

We also have those:

https://dlang.org/library/std/variant/variant_array.html