On Tuesday, 21 June 2022 at 08:55:19 UTC, Ola Fosheim Grøstad wrote:

D will do anything to not have class private.

On Tuesday, 21 June 2022 at 10:36:32 UTC, The Zealot wrote:

invariant(default)
    {
        assert(1 <= day && day <= 31);
        assert(0 <= hour && hour < 24);
    }
invariant(always) {
        assert(1 <= sec && sec <= 60);
}

You can already do this, just add an or-clause to a compile time boolean constant.

assert((!precise_invariant) || (1 <= day && day <= 31));

But the class invariant should only be tested on member-function entry in debug-mode.

In release mode the invariant should be assumed to hold on entry and can be used for optimizations (it should still be tested on exit).

So this:

class always_even {
   private int x;
   invariant { assert(x%2==0); }
   void triple(){
      x *= 3;
      if (x&1) writeln("found one");
   }
   // more code
}

should become this:

class always_even {
   private int x;
   tripple(){
      // assume(x%2==0)
      x *= 3;
      assert(x%2==0);
   }
   …
}

Or even this (with a decent optimizer):

class always_even {
   private int x;
   tripple(){
      // assume(x%2==0)
      x *= 3;
      // assert(x%2==0);
   }
   …
}

With invariants turned off, the result will be worse as there is no indication that the lowest bit of x is constant 0:

class always_even {
   private int x;
   void triple(){
      x *= 3;
      if (x&1) writeln("found one");
   }
   …
}

On Tuesday, 21 June 2022 at 11:06:17 UTC, bauss wrote:

Yes, but you can do it with @UDA + linter.

That is a much better approach than getting more complexity into the language (anything more complex than a «hidden» specifier should be rejected)

On Tuesday, 21 June 2022 at 11:23:36 UTC, Ola Fosheim Grøstad wrote:

I don't agree that it's a better approach because then you also have to use a linter and can't just resort to using the compiler.

Unless D shipped with a linter that worked with every editor and/or could be put into your build system easily, then I don't think it's a better solution.

I'd much rather have the compiler yield an error to me and then fix that, than relying on yet another third party tool.

On Tuesday, 21 June 2022 at 11:20:46 UTC, Ola Fosheim Grøstad wrote:

invariant(default)
    {
        assert(1 <= day && day <= 31);
        assert(0 <= hour && hour < 24);
    }
invariant(always) {
        assert(1 <= sec && sec <= 60);
}

assert((!precise_invariant) || (1 <= day && day <= 31));

class always_even {
   private int x;
   invariant { assert(x%2==0); }
   void triple(){
      x *= 3;
      if (x&1) writeln("found one");
   }
   // more code
}

class always_even {
   private int x;
   tripple(){
      // assume(x%2==0)
      x *= 3;
      assert(x%2==0);
   }
   …
}

class always_even {
   private int x;
   tripple(){
      // assume(x%2==0)
      x *= 3;
      // assert(x%2==0);
   }
   …
}

class always_even {
   private int x;
   void triple(){
      x *= 3;
      if (x&1) writeln("found one");
   }
   …
}

sorry, i wasn't clear what i meant. i meant add the ability to control when invariants checks are inserted by the compiler. for example a way to specify that you want the invariant checked after each access to any member, as well as "the class invariant should only be tested on member-function entry in debug-mode".
but it's mainly a suggestion for performance reasons.

On Tuesday, 21 June 2022 at 12:18:35 UTC, bauss wrote:

I do agree that it shouldn't be more complex than just a "hidden" keyword tho.

Ex. hidden int x should be the only thing, nothing more and nothing less.

I don't think it's necessary to add anything more complex like controlling who has access etc.

On Tuesday, 21 June 2022 at 12:18:35 UTC, bauss wrote:

I'd rather see nothing than more annoying syntax.

Since over half of all class attributes should be class-private the syntax has to be short and clean.

On Tuesday, 21 June 2022 at 12:20:15 UTC, bauss wrote:

Ah, ok. So we agree :)

On Tuesday, 21 June 2022 at 11:06:17 UTC, bauss wrote:

To the contrary, it doesn't have that today and is doing nothing.

If you want it to do something, you need to justify that it is worth doing.

So far, all we got is "This is mandatory as per my definition of OOP", which is not a convincing argument.

This is especially not convincing because many people here have been using D for many years, and most of them had a "hu, that's weird" moment when they figured out how private was working. And then figured out that the current behavior is actually much more useful in practice.