Future of memory management in D

[Atila Neves]

On Thursday, 18 November 2021 at 14:56:40 UTC, rumbu wrote:
> 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:
>
>>> * 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)
>
> ```

Is the point here to make sure that a struct implements a given 
interface? Because, if so:

https://github.com/atilaneves/concepts#using-a-d-interface-to-specify-compile-time-template-constraints

I hadn't thought about functions that can take a dynamic or 
static type though, which is interesting.

>>> * 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!
> ```

Works with `ref prop() { return _fld; }`.

>>> * 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");
> }
>
> ```

std.sumtype?