If we want multiple inheritance or even virtual methods in structs, completely new and severe problems appear. And I don't think these patterns have utility that justifies these problems or even their existence alone.

Single struct inheritance with no virtual methods presents in my opinion no problems, and it would be in many cases a better, more concise, boilerplate-less, clearer, cleaner way to accomplish the type extension and not repeating oneself that currently we can do only by composition and explicit forwarding, alias this, or macro-ish template mixins.

On Saturday, 22 June 2019 at 06:29:43 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 21 June 2019 at 22:19:12 UTC, bioinfornatics wrote:
>> struct Employee{
>>   delegate: get_age, to: _person
>>   delegate: get_experience, to: _career
>>
>>   immutable Person _person;
>>   immutable Career _career;
>
> Listing all methods isn't very helpful, if that is the suggestion. Then a more consistent syntax would be
>
> struct Employee {
> alias getage = _person.getage;
> alias get_experience = _career.get_experience;

Explicit forwarding is already/always possible. These syntaxes are not so more concise than

auto getAge() { return _person.getAge(); }

So I'd see no point in burdening D with adding such candy features.

On Saturday, 22 June 2019 at 07:10:26 UTC, XavierAP wrote:
> If we want multiple inheritance or even virtual methods in structs, completely new and severe problems appear. And I don't think these patterns have utility that justifies these problems or even their existence alone.
>
> Single struct inheritance with no virtual methods presents in my opinion no problems, and it would be in many cases a better, more concise, boilerplate-less, clearer, cleaner way to accomplish the type extension and not repeating oneself that currently we can do only by composition and explicit forwarding, alias this, or macro-ish template mixins.
>
> On Saturday, 22 June 2019 at 06:29:43 UTC, Ola Fosheim Grøstad wrote:
>> On Friday, 21 June 2019 at 22:19:12 UTC, bioinfornatics wrote:
>>> struct Employee{
>>>   delegate: get_age, to: _person
>>>   delegate: get_experience, to: _career
>>>
>>>   immutable Person _person;
>>>   immutable Career _career;
>>
>> Listing all methods isn't very helpful, if that is the suggestion. Then a more consistent syntax would be
>>
>> struct Employee {
>> alias getage = _person.getage;
>> alias get_experience = _career.get_experience;
>
> Explicit forwarding is already/always possible. These syntaxes are not so more concise than
>
> auto getAge() { return _person.getAge(); }
>
> So I'd see no point in burdening D with adding such candy features.

Thanks for your insight.
So I have a question what solve the struct inheritance which can not be done by the use of method forwarding?

To me the template proxy is the way to go. They are no needs to extend the dlang syntax.

Case 1: too few people know it
Case 2: struct inheritance solve things that can not be done using the proxy

https://dlang.org/library/std/typecons/proxy.html

On Monday, 24 June 2019 at 16:13:05 UTC, bioinfornatics wrote:
>
> Thanks for your insight.
> So I have a question what solve the struct inheritance which can not be done by the use of method forwarding?

Less typing (cleaner, better code) and subtyping/polymorphism.

Of course every language feature could be implemented from scratch in C. But if we're using other languages it's because their features are useful.

> To me the template proxy is the way to go. They are no needs to extend the dlang syntax.
>
> Case 1: too few people know it
> Case 2: struct inheritance solve things that can not be done using the proxy
>
> https://dlang.org/library/std/typecons/proxy.html

Proxy behaves (is purposely designed to behave) quite differently from inheritance... But to answer the general proposition that it's best to eliminate inheritance and implement it from templates, I think it makes no sense in principle because templates are more complex, both in code and under the hood (of the compiler specially). Inheritance (without virtual/dynamic dispatch) is as simple as aligning a few bytes together with the base type's ones.

There are fads in patterns, and nowadays people are against inheritance. Little ago templates were the answer to everything, just like OOP was in the 90s (of course templates are extremely useful). Their use pushed compilation times and code readability out of orbit. Nowadays quite some people are reacting by going back to C, plain composition, and their dogma is that dangling pointers are the least problem.

D was purposely created not to follow one single paradigm, but to offer all modern, proven ones to discerning programmers.

On Monday, 24 June 2019 at 21:13:17 UTC, XavierAP wrote:
> Nowadays quite some people are reacting by going back to C, plain composition, and their dogma is that dangling pointers are
> the least problem.

These people are insane. Long compile times and high compile memory usage create problems for developers. Dangling pointers create problems for developers AND users (very nasty problems at that).

C cannot die quickly enough. We should be working to kill it, not bring about its resurgence.

On Monday, 24 June 2019 at 21:20:21 UTC, Meta wrote:
> On Monday, 24 June 2019 at 21:13:17 UTC, XavierAP wrote:
>> Nowadays quite some people are reacting by going back to C, plain composition, and their dogma is that dangling pointers are
>> the least problem.
>
> These people are insane. Long compile times and high compile memory usage create problems for developers. Dangling pointers create problems for developers AND users (very nasty problems at that).
>
> C cannot die quickly enough. We should be working to kill it, not bring about its resurgence.

C++ is more so the one with how long it takes to compile. C isn't that bad. I don't see anything replacing C, there are a number of different languages that could but they are all fragmented.

DMD can eat a lot of memory, it also isn't very efficient.

static foreach(i; 0 .. 0xFFFF) {}

the above code eats up over 12 GB of RAM. That's all my free RAM + whatever it is using on my drive. It also takes a REALLY long time to execute, at least an hour. I gave up after that. Spends almost all of it's time doing Array operations. DMD has a really weird implementation of Array, looks like it was implemented possibly in D1 days. Reserve(int) is additive, sure fine w/e. Passing around arrays as points, so need to dereference them to actually use them... Then you have insert(Range) that does a reserve(), which allocates new memory, copies all the data. Then the insert moves all the data it just copied. Sure the code is simpler but it has horrible performance, especially when there is a loop that is constantly adding and removing from the front/middle of the array.

On Wednesday, 19 June 2019 at 01:10:56 UTC, Manu wrote:
> On Wed, Jun 19, 2019 at 10:45 AM Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>
>> On 6/18/2019 5:01 PM, Timon Gehr wrote:
>> > This works if Base and Derived are defined in the same module. Otherwise this does not do the correct thing, because mixin templates are analyzed in the scope into which they are mixed.
>>
>> That is correct, but with some care you can make it work, even if the mixin template functions just forward to other functions which are evaluated in the BaseMembers' scope.
>
> I already have workarounds. That's not what this thread is about.

Not just my opinion, but what I perceive to be expected procedure here:
   The merits of any new feature have to be argued in terms of net benefit over existing solutions.

Just my opinion:
    The best feature design often comes from struggling with current features.

You obviously have done a lot of the second, but it seems that you think "it's obviously better, the current solutions are just ugly hacks, everyone will laugh at us" is going to convince people enough w.r.t. the former.

Obvious hyperbole is obvious, but hopefully you get my point?

On Sunday, 9 June 2019 at 08:05:34 UTC, Manu wrote:
> Imagine if we could just write:
>
> struct DerivedStruct : BaseStruct
> {
>     // derived members
>     //...
> }
>
> Just imagine!

Mhmm...

 I'd think struct inheritance would follow the original C++'s ideology.

 So probably:

 1) No Virtual functions. All functions are FINAL (replacing)
 2) No polymorphism.
 3) Limited casting (Casting up/back is easier than casting down, with space limitations in mind), though casting could simply be disallowed but that seems unlikely when you get low level.

 In such a case you could build a base struct and then add onto it for several structs behaviors. Being able to avoid using the GC as much as possible that would help. Also most of the functions/structures are basically copy/pasted with overriding functions completely replacing the previous ones.

 I've been wanting this for a while. I had a prototype set of templates to do this very thing! But... it no longer works, hasn't since... oh i don't remember. I'd have to pull the old files out...

 I'd probably ask a debugging feature where you could output the new finalized struct in it's full source code or maybe rather just it's API specifying what functions/variables come from where, so you get a clear picture of what you're working with if you inherit several times/deep.

On Tuesday, 2 July 2019 at 04:54:07 UTC, Era Scarecrow wrote:
>  1) No Virtual functions. All functions are FINAL (replacing)
>  2) No polymorphism.
>  3) Limited casting (Casting up/back is easier than casting

 And looking at my old notes... Might make it where the data size can't change.

 This crypto stuff used to work in 10/2012, or with DMD 2.060

From the polymorph.d
---
  auto crypto = PolyCryptoBase.factory("CryptoROT13");
  crypto.setString("(Whfg n yvggyr pelcgb grfg)");
  crypto.encipher;
  assert(crypto.data.crypted == "(Just a little crypto test)");
---

Here's a crypto example of the actual structs

/** This is not intended as a serious crypto library, just enough to test several factors to ensure the polymorphic
    nature is being done. As other items need to be tested this crypto will be improved to handle those tests.*/
struct PolyCryptoBase {
    ///Enum, _prefix and _types don't exist until this calls.
    mixin(expandTypes("Data", "Poly_", "CryptoBase,CryptoXOR13,CryptoROT13"));

    ///
    struct Data {
        Enum polyMorphType; ///
        string original; ///
        char[] crypted;    ///mutable copy
    }
    Data data; ///

    ///Seems opCmp opEquals and similar functions go in the poly base. That's livable.
    ///if not, forward reference to Poly_opCmp

    mixin PolyMorphicCompare!(PolyCryptoBase);
    mixin PolyMorphic!("smartmerged.polymorphicstruct_crypto", PolyCryptoBase, Data, "data"); ///
}

///
struct CryptoBase {
    mixin PolyMorphicInclude!(PolyCryptoBase); ///

    ///Seems opCmp opEquals and similar functions go in the poly base. That's livable.
    ///if not, forward reference to Poly_opCmp
    int Poly_opCmp(ref const PolyCryptoBase rhs) const {
        return data.original.length - rhs.data.original.length;
    }

    ///if it matches the original string
    bool isCrypted() @property pure @safe nothrow{
        return data.original != data.crypted;
    }

    ///Does basic enciphering, individual letters only
    static void Poly_cipherChar(ref char c) pure @safe nothrow {
        c ^= 127;
    }

    ///set the plaintext (resetting crypted text as well)
    void setString(string input) @property {
        data.original = input;
        data.crypted = input.dup;
    }

    ///encrypt cipher string (which done twice will decrypt it)
    void encipher() @property {
        foreach(ref ch; data.crypted) {
            this.cipherChar(ch);
        }
    }
}

///
struct CryptoXOR13 {
    mixin PolyMorphicInclude!(PolyCryptoBase);///

    /**non matching signatures, but still compatible
       requires 'static' or const to work, otherwise
       potential for only calling a different version
       may apply making some bugs hard to find.*/
    static void cipherChar(ref char c) pure @safe {
        c ^= 13;
    }
}






Yeah a little long winded, but it did work as a concept... I can share the old full sources if you want.