Extending D's support for object-oriented design with private(this)

[NotYouAgain]

Jonathan M Davis wrote:

> On Tuesday, May 21, 2024 3:50:38 AM MDT Quirin Schroll via 
dip.ideas
> wrote:
>> On Saturday, 27 April 2024 at 07:39:19 UTC, Jonathan M Davis
>>
>> wrote:
>> > (particularly since the change from private, public, etc. being
>> > protection attributes to visibility attributes seems to have
>> > been tricky enough that a number of subtle bugs were introduced
>> > in the process).
>>
>> I know this is slightly off-topic, but I have two questions about
>> that:
>> 1. When did this happen? I don’t need an exact date, but before
>> 2015 and after 2015 would be helpful to me because I started
>> learning D end of 2015 and so I could know if I ever used D with
>> the old “protection attributes” way.
> 
> It was DIP 22:
> 
> https://github.com/dlang/DIPs/blob/master/DIPs/archive/DIP22.md
> 
> It looks like the original changes were merged in 2016.
> 
>> 2. What is the difference? I don’t need details, maybe a single
>> example does the job.
> 
> Before DIP 22, functions which the code did not have access to 
(e.g. a
> private function in another module) were considered to be part of 
the
> overload set but then resulted in an error when a function which 
the
> calling code didn't have access to was the best match. This meant 
that
> simply adding a private function to your module could break 
someone else's
> code if it happened to be a better match for the arguments than 
the
> overload that they'd been using. E.G. maybe they had a function 
foo(long),
> and you added a private foo(int) to a module that they imported, 
then any
> calls to foo with integer literals - like foo(42) - would suddenly 
try to
> call your function instead of theirs, resulting in an error, since 
it was
> private.
> 
> After DIP 22, functions which the code does not have access to are 
not
> considered part of the overload set. So, if you have multiple 
functions
> with the same name which could match, a function which that code 
does not
> have access to will no longer result in an error. Instead, you'll 
get the
> best match out of the functions that you actually have access to. 
So,
> adding a private foo(int) to your module won't suddenly result in 
foo(42)
> trying to call your foo instead of the foo(long) that the code was 
already
> using.
> 
> So before, private, public, etc. were protection modifiers / 
attributes,
> and now they're visibility modifiers / attributes, since before, 
they
> controlled whether you had access to a symbol, whereas now, they 
control
> whether that symbol is visible. You can still get at the private 
stuff via
> traits, but otherwise (barring compiler bugs), the private symbols 
don't
> exist for modules that import that module, and you won't get 
breakage just
> because the list of private symbols in a module that you're 
importing
> changes.
> 
> - Jonathan M Davis

well, as long as mike-the-moderator keeps deleting news posts, 
nobody will know the facts. they'll only know what mike-the-
moderator wants them to know.