article comparing Rust and Zig, many points relevant to D

[Adam D. Ruppe]

On Wednesday, 10 March 2021 at 22:08:43 UTC, H. S. Teoh wrote:
> IMO this should generate an ambiguity error.  But I don't know 
> the current behaviour.

At the top level, it will always use the top-level name. This 
allows for easy overriding, like with the adrdox 
`declarationType` method in my previous message.

mixin templates seem to be fairly poorly understood in the 
community. I wrote a little about them here:

http://dpldocs.info/this-week-in-d/Blog.Posted_2020_01_20.html#understanding-mixin-templates

about a year ago, but perhaps more needs to be written.

They are NOT copy/pasted code, that's closer to what string mixin 
is (and it isn't copy/pasted code either, but rather copy/pasted 
AST nodes but I digress). The common name "mixin" makes you think 
they're the same, but they are very different beasts.

Template mixins are more like a separate struct that allows name 
as well as virtual slot forwarding to the surrounding context 
(but notably operator overloading is NOT considered, and function 
overloading is not automatic, requiring an `alias` bridge since 
the mixin template and the parent are two separate contexts with 
name-based overriding, not signature-based). It is a fairly 
unique concept but the behaviors are all there for a reason and 
once you know those reasons, you can do a lot of cool things with 
them.

The biggest worry is overloading constructors, there I'd argue it 
is a bug / oversight. You can alias in __ctor... sometimes. 
Otherwise the `this` keyword isn't allowed by the syntax meaning 
the proper procedure doesn't work.

But most everything else works well once you get to know it.