Why do private member variables behaved like protected in the same module when creating deriving class?

[Patrick Schluter]

On Thursday, 1 November 2018 at 14:28:27 UTC, Atila Neves wrote:
> On Tuesday, 30 October 2018 at 08:18:57 UTC, Bastiaan Veelo 
> wrote:
>> On Tuesday, 30 October 2018 at 00:01:18 UTC, 
>> unprotected-entity wrote:
>>> On Monday, 29 October 2018 at 22:24:22 UTC, Bastiaan Veelo 
>>> wrote:
>>>>
>>>> I hear you and understand you, but personally I still prefer 
>>>> the D spec as it is in this regard, except for the confusing 
>>>> aspect that you shouldn’t `alias this` a private member; but 
>>>> that is rather a limitation of alias, not of encapsulation.
>>>>
>>>
>>> If your were sitting on a plane that was running the 
>>> following D code, you might think differently ;-)
>>>
>>> --------
>>> class Plane
>>> {
>>>     private static int MAX_SPEED = 1000;
>>>
>>>     public void change_max_speed(int speed)
>>>     {
>>>         if(speed >= 1000)
>>>             MAX_SPEED = speed;
>>>     }
>>>
>>> }
>>>
>>> immutable Plane p = new Plane();
>>>
>>> // god no! why aren't you using the public interface of the 
>>> class for this!
>>> void SetMaxSpeed() { p.MAX_SPEED = -1; }
>>>
>>> void Bar() { SetMaxSpeed(); } // mmm...trouble is about to 
>>> begin...
>>>
>>> void main()
>>> {
>>>     import std.stdio;
>>>
>>>     Bar(); // oohps. thanks D module. we're all going to die!
>>>
>>>     // by the time you see this, it's too late for you, and 
>>> your passengers.
>>>     writeln(p.MAX_SPEED);
>>>
>>> };
>>>
>>>
>>> -------
>>
>> :-) Why is MAX_SPEED mutable or even a runtime value, let 
>> alone signed?
>
> Strictly my opinion below, but I believe wholeheartedly in this:
>
> Using unsigned integers for anything except bit patterns and 
> talking to hardware is an open invitation to bugs. The C++ 
> community has recognised this and admitted that using size_t 
> everywhere in the STL was a mistake.
>
> "Ah, but I want type safety!". Uh-huh:
>
> -----------------
> int[] ints;
> // indexing uses size_t, but...
> auto i = ints[-1];  // look ma, no errors or warnings!
> -----------------
>
> The problem in D and C++ is that they inherit behaviour from C, 
> and in this case the important part of that inheritance is that 
> integers of different types convert implicitly to each other. 
> There is *no* type-safety when using unsigned integers. And 
> because bit-patterns and actual integers share the same type 
> now, people will invariably do something "they're not supposed 
> to" and perform arithmetic with these values and usually wrap 
> around. It's not pretty and it's not fun to debug.
>
> I have literally lost count of how many bugs I've had to fix 
> due to unsigned integers. `long` is large enough for anything 
> you need, as Java has shown for 2 decades now.
>
> Friends don't let friends use unsigned types for counting.

My experience is exactly the opposite. I inherited a code base of 
~200K lines of C written over 3 decades by several developers of 
varying skills. You can not imagine how many bugs I found thanks 
to replacing int and long by size_t and uint32_t/uint64_t.

int i = 0;
ints[--i];  // look ma, no errors or warnings! indeed

with size_t i at least you get segfault or a bus error.

The worst offense is using int on 64 bit machines when working on 
big datasets, overflows are really more common than people expect.

When using unsigned, it requires indeed to be careful when 
interacting with other variable, but since when is sloppiness a 
virtue?
The thing is, all the code that used int as a default was code 
that was not thought through concerning the range of values and 
limits of the used variables.