On 6/12/2019 11:29 PM, Manu wrote:
> On Wed, Jun 12, 2019 at 10:25 PM Walter Bright via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>>
>> On 6/11/2019 11:19 AM, Manu wrote:
>>>> Can I ask again, in a different way, why do you need the 0 size?
>>>
>>> To handle base structs with no members.
>>
>> For the 3rd time, why do you need it to have 0 size? I don't know what you mean
>> by "handling" it.
> 
> I hate wasting 8 bytes needlessly. Almost every struct I write is
> carefully packed and aligned to 16, 32, or 64 bytes and allocated in
> pools... that's 50%, 25%, or 12.5% memory wastage.
> There's also ABI compatibility with existing C++ where this is
> super-common. Consider that user-supplied <Allocator> is a base of
> every STL container, that's one case where I've had to deploy the
> static if hack a lot. Those are absolutely not polymorphic types, and
> you couldn't make that mistake no matter how hard you squinted. They
> sometimes use a helper called a 'packed pair' in the STL, which is
> like std::pair (obviously another not-a-polymorphic-type), but where
> one or the other element can be zero-sized and not waste memory.
> It's an aggregation tool.
> 

Have you considered using template mixins? Since you're using a base struct merely as a namespace for some functions, that should work.

On 6/13/2019 5:03 AM, Timon Gehr wrote:
> I think a lot of the default opposition to new features (especially if they can be implemented with a moderate amount of user code) is about DMD compiler complexity, about adding new things to a code base which already suffers quite a bit from incidental complexity.

D has a TON of features. And yet every single day, people demand ever more features. How can this possibly work without turning D (and the compiler) into a unusable mess. I have no choice but to constantly say "no".

As for struct inheritance, it seems what Manu really wants isn't struct inheritance at all, it is zero sized structs having zero size when they are used as fields.

First off, he has a workaround for it. I agree it's not very pretty, but it works and he is not blocked. That moves it way down on the priority list.

Secondly, there are template mixins, which have zero size.

On Tuesday, 18 June 2019 at 09:15:42 UTC, Walter Bright wrote:
> On 6/12/2019 11:29 PM, Manu wrote:
>> There's also ABI compatibility with existing C++ where this is
>> super-common. Consider that user-supplied <Allocator> is a base of
>> every STL container, that's one case where I've had to deploy the
>> static if hack a lot.
>
> Have you considered using template mixins? Since you're using a base struct merely as a namespace for some functions, that should work.

The ABI compatibility point really needs to be reiterated here. If the end goal, especially with things like D++, is to drive adoption of D by ensuring C++ interop is simple then that's now going to result in a static analysis tool to look at any given C++ struct and work out whether it should or shouldn't be converted to a mixin template. And introduce the dissonance of a C++ type not actually being a type in D.

On 18.06.19 11:23, Walter Bright wrote:
> On 6/13/2019 5:03 AM, Timon Gehr wrote:
>> I think a lot of the default opposition to new features (especially if they can be implemented with a moderate amount of user code) is about DMD compiler complexity, about adding new things to a code base which already suffers quite a bit from incidental complexity.
> 
> D has a TON of features. And yet every single day, people demand ever more features. How can this possibly work without turning D (and the compiler) into a unusable mess.

As far as I can tell, a lot of the incidental complexity is introduced in bug fixes. Furthermore, the issue is:
- features whose implementation is spread all over the code base without an easy way to find all components of their implementation.
- features that should work the same (e.g. @nogc inference and pure inference) that have a different and incompatible implementation.

> I have no choice but to constantly say "no".
> ...

I agree it is a useful default stance.

On Tue, Jun 18, 2019 at 7:20 PM Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On 6/12/2019 11:29 PM, Manu wrote:
> > On Wed, Jun 12, 2019 at 10:25 PM Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> >>
> >> On 6/11/2019 11:19 AM, Manu wrote:
> >>>> Can I ask again, in a different way, why do you need the 0 size?
> >>>
> >>> To handle base structs with no members.
> >>
> >> For the 3rd time, why do you need it to have 0 size? I don't know what you mean by "handling" it.
> >
> > I hate wasting 8 bytes needlessly. Almost every struct I write is
> > carefully packed and aligned to 16, 32, or 64 bytes and allocated in
> > pools... that's 50%, 25%, or 12.5% memory wastage.
> > There's also ABI compatibility with existing C++ where this is
> > super-common. Consider that user-supplied <Allocator> is a base of
> > every STL container, that's one case where I've had to deploy the
> > static if hack a lot. Those are absolutely not polymorphic types, and
> > you couldn't make that mistake no matter how hard you squinted. They
> > sometimes use a helper called a 'packed pair' in the STL, which is
> > like std::pair (obviously another not-a-polymorphic-type), but where
> > one or the other element can be zero-sized and not waste memory.
> > It's an aggregation tool.
> >
>
> Have you considered using template mixins? Since you're using a base struct merely as a namespace for some functions, that should work.

I mean, I love macro's as much as the next guy, and they're not at all embarrassing.

On Tue, Jun 18, 2019 at 7:25 PM Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On 6/13/2019 5:03 AM, Timon Gehr wrote:
> > I think a lot of the default opposition to new features (especially if they can be implemented with a moderate amount of user code) is about DMD compiler complexity, about adding new things to a code base which already suffers quite a bit from incidental complexity.
>
> D has a TON of features. And yet every single day, people demand ever more features. How can this possibly work without turning D (and the compiler) into a unusable mess. I have no choice but to constantly say "no".

I'm pretty much just into feature uniformity at this stage. D's
biggest problem from my perspective is "weird shit", mostly
non-uniform arbitrary limitations and strange edge cases.
And also that shared doesn't work.

> As for struct inheritance, it seems what Manu really wants isn't struct inheritance at all, it is zero sized structs having zero size when they are used as fields.

As base structs specifically. I really want struct inheritance, and
zero sized fields does happen to be one thing that falls out of that.
There are 2 things I hate about it; one is the crappy static-if hack
required to deal with zero-sized bases, the other is that I have to
use `alias this` to describe a base.
alias this *should* be a very niche feature, but instead we abuse it
in lieu of struct inheritance, and no way to perform implicit
conversion. In both cases it's a gross code smell, and I hate it.

> First off, he has a workaround for it. I agree it's not very pretty, but it works and he is not blocked. That moves it way down on the priority list.

I agree. The thread was just to re-iterate my strong discontent, and frankly, boredom with the situation.

> Secondly, there are template mixins, which have zero size.

That's feels even worse than my crappy hack to me.
Anyway, shared is my #1 concern.

On Tuesday, 18 June 2019 at 09:23:45 UTC, Walter Bright wrote:
> As for struct inheritance, it seems what Manu really wants isn't struct inheritance at all, it is zero sized structs having zero size when they are used as fields.

Quick question, have you considered the following syntax:

    align(0) struct MyEmptyStruct {};

or some other means of saying "I don't intend to take this struct's address, I don't mind if it takes zero bytes of space"?

On Tuesday, 18 June 2019 at 12:17:36 UTC, Manu wrote:
> As base structs specifically. I really want struct inheritance, and
> zero sized fields does happen to be one thing that falls out of that.
> There are 2 things I hate about it; one is the crappy static-if hack
> required to deal with zero-sized bases, the other is that I have to
> use `alias this` to describe a base.
> alias this *should* be a very niche feature, but instead we abuse it
> in lieu of struct inheritance, and no way to perform implicit
> conversion. In both cases it's a gross code smell, and I hate it.

It might be because I write a lot less generic code than you do, but I really don't understand why you lend so much importance to implicit conversion.

XavierAP's question is particularly relevant here:

> What is the benefit of
>
> 	struct A { void fun(); };
> 	struct B :A {};
>
> 	B b;
> 	b.fun;
>
> compared to
>
> 	struct A {};
> 	struct B { A a; };
>
> 	B b;
> 	b.a.fun;
>

Like, seriously, I might be missing something, but I don't get it.

Can you cite some use case where inheritance is convenient but composition isn't? Ideally an actual use case that came up in a project?

On 6/18/2019 5:07 AM, Timon Gehr wrote:
> As far as I can tell, a lot of the incidental complexity is introduced in bug fixes.

I've caught a lot of PRs for fixes that were incorrect. A lot slip by me.

> Furthermore, the issue is:
> - features whose implementation is spread all over the code base without an easy way to find all components of their implementation.

You're absolutely right on that. I really want to encapsulate this stuff - most recently https://github.com/dlang/dmd/pull/9993

> - features that should work the same (e.g. @nogc inference and pure inference) that have a different and incompatible implementation.

Generally that is the result of incremental accretion of features.

On 6/18/2019 5:17 AM, Manu wrote:
> Anyway, shared is my #1 concern.

The more I've read about and studied concurrent programming issues, I tend to agree with you. If not #1, it's near #1.