Future of memory management in D

[rumbu]

On Thursday, 18 November 2021 at 13:37:28 UTC, Atila Neves wrote:
> On Thursday, 18 November 2021 at 04:24:56 UTC, rumbu wrote:

>> * wrong idea of what private means (yes, I know that you 
>> disagree on that, but every OOP book/study/reference considers 
>> the class as unit of encapsulation);
>
> As you've mentioned, we're not going to agree. I don't think 
> this is failing to evolve either since it's by design.

Let's agree to disagree. For me, it's a failure.

>> * struct inheritance
>
> Inheritance (subtyping) and value types don't mix.

A struct can inherit 2 things:
- another struct
- an interface

This doesn't involve boxing for structs, just the compiler 
generating a templated function when encounters the interface as 
a parametter. At least this is how it is done in BeefLang.

```d
interface I { void foo(); }

void bar(I i)
{
    i: foo;
}

class C: I { void foo() {} }
struct S: I { void foo() {} }

C c = new C();
S s = new S();

void callMe(I i) { i.foo }

callMe(c); // compiler will call callMe as usual
callMe(s); // compiler will generate and call a specialized 
callMe(S i)

```
> Could you please explain what these mean?
>
>>explicit interface implementations


```d
interface I1 { void foo(); }
interface I2 { void foo(); }

class C : I1, I2
{
     void foo() { writeln ("I am I1's and I silently hide I2's 
foo"); }
     void I1.foo() {writeln("I am I1's foo"); } //this doesn't work
     void I2.foo() {writeln("I am I2's foo"); } //this doesn't work
}

```

>> class destructuring

I already explain it, controlled decomposing of classes or 
structs;

```d

//if tuple syntax was built-in (item1, item2, ....)
struct Coordinate
{
    int x, y, z;
    void opDeconstruct(out x, out y) { return (x, y) }
    void opDeconstruct(out x, out y) { return (x, y, z) }
}

Coordinate co;

(x,y) = co;
(x,y,z) = co;

```
>
>> * properties
>
> What's missing?

A better syntax? Compiler generated backing fields? The fact they 
are not working as advertised?

```d
class C
{
     int _fld;
     int prop() {return _fld;}
     void prop(int x) { _fld = x; }
}

C c = new C();
c.prop += 42;  ///oops!
```

>
>> * pattern matching on class type
>
> AFAIC this is an anti-pattern. IMHO, in OOP, there should be a 
> switch exactly in one place in the program, and that's where 
> instances get created. I don't know why anyone would want to 
> recreate the functionality of the virtual table in an ad-hoc 
> way.
>
> Multiple dispatch blurs this, however.
>
>> * pattern matching on fields/properties
>
> How would this work?


```d
switch (JSONValue)
{
    case JSONNumber n: writeln ("I have a number %s", n);
    case JSONString s when s.Length > 100 : writeln("long string");
    case JSONString s: writeln("short string");
}

```