On 20.12.18 17:10, H. S. Teoh wrote:
> 
> IIRC, that PR was blocked because of disagreements over how ambiguous
> symbols over multiple alias this types would be resolved.  Somebody
> needs to come up with a DIP with well-defined semantics for all the
> details and corner cases before this can move forward.

But it's a solved problem. Just make `alias this` exactly like `import`.

On 12/20/2018 10:38 AM, H. S. Teoh wrote:
> There has been multiple attempts to implement it, but none were
> persistent enough to see it through to the finish line.

Nobody has figured out the semantics of single alias this, either (when faced with class inheritance). The bugzilla issues for it are ample evidence.

MI is a Hansel and Gretel feature, where it appears to be all gingerbread and candy, but the witch inevitably appears to pop you in the oven.


Other Hansel and Gretel features:

1. monkey patching
2. macros
3. implicit variable declaration
4. preprocessor

On 12/20/2018 7:21 PM, Timon Gehr wrote:
> But it's a solved problem. Just make `alias this` exactly like `import`.

Imports don't have adjuster thunks, implicit cast issues, slicing, or empty base optimizations. Import lookup in a class is different because of the two-phase nature of it (people complained bitterly about the earlier single phase lookup).

Import lookup doesn't have to conform to the relevant undocumented C++ ABI, either. (It was about a year of bug reports until I was finally able to match Microsoft C++'s MFC behavior for MI struct layout.)

  class C : B {
    B b;
    alias b this;
  }

Now what? (This is not specified in the dlang spec.)

On 12/20/2018 7:14 PM, Nicholas Wilson wrote:
> If you do struct "inheritance" with alias this, because there is no multiple alias this, you can't then alias this the struct to something else.

Ok.

I suggest using aggregation rather than attempting multiple inheritance.

On 12/19/2018 5:40 PM, Manu wrote:
> It also wastes the single `alias this` slot that we get in a
> no-multiple-alias-this world.
> 
> As far as I can tell, the decision is arbitrary... can we move past this?


T.A. Cargill's famous paper about multiple inheritance:

"Controversy: The Case Against Multiple Inheritance in C++"

https://www.usenix.org/legacy/publications/compsystems/1991/win_cargill.pdf

On 21/12/2018 5:09 PM, Walter Bright wrote:
> On 12/20/2018 7:21 PM, Timon Gehr wrote:
>> But it's a solved problem. Just make `alias this` exactly like `import`.
> 
> Imports don't have adjuster thunks, implicit cast issues, slicing, or empty base optimizations. Import lookup in a class is different because of the two-phase nature of it (people complained bitterly about the earlier single phase lookup).
> 
> Import lookup doesn't have to conform to the relevant undocumented C++ ABI, either. (It was about a year of bug reports until I was finally able to match Microsoft C++'s MFC behavior for MI struct layout.)
> 
>    class C : B {
>      B b;
>      alias b this;
>    }
> 
> Now what? (This is not specified in the dlang spec.)

Type Declaration -> alias this [0 .. $]

At declaration site or the alias this, if it is not free-of-issues, error.

Say didn't we have a DIP that was accepted for multiple alias this?

On Thu., 20 Dec. 2018, 7:35 pm Walter Bright via Digitalmars-d < digitalmars-d@puremagic.com wrote:

> On 12/20/2018 10:38 AM, H. S. Teoh wrote:
> > There has been multiple attempts to implement it, but none were persistent enough to see it through to the finish line.
>
> Nobody has figured out the semantics of single alias this, either (when
> faced
> with class inheritance). The bugzilla issues for it are ample evidence.
>
> MI is a Hansel and Gretel feature, where it appears to be all gingerbread
> and
> candy, but the witch inevitably appears to pop you in the oven.
>
>
> Other Hansel and Gretel features:
>
> 1. monkey patching
> 2. macros
> 3. implicit variable declaration
> 4. preprocessor
>

I don't think I've ever wanted multiple inheritance in D, but I do want implicit conversions very often, and occasionally multiple implicit conversions.

>

On Friday, 21 December 2018 at 03:33:05 UTC, Walter Bright wrote:
> On 12/20/2018 10:38 AM, H. S. Teoh wrote:
>> There has been multiple attempts to implement it, but none were
>> persistent enough to see it through to the finish line.
>
> Nobody has figured out the semantics of single alias this, either (when faced with class inheritance). The bugzilla issues for it are ample evidence.
>
> MI is a Hansel and Gretel feature, where it appears to be all gingerbread and candy, but the witch inevitably appears to pop you in the oven.
>
>
> Other Hansel and Gretel features:
>
> 1. monkey patching
> 2. macros
> 3. implicit variable declaration
> 4. preprocessor

I don't think any lisper has ever complained about Lisp macros - on the contrary, it's considered one of Lisp's killer features. It's a shame they're inextricably linked to the syntax (or lack thereof) and that nobody has yet figured out a good macro system that doesn't depend on S-expressions.

On 12/21/2018 2:42 AM, Atila Neves wrote:
> I don't think any lisper has ever complained about Lisp macros - on the contrary, it's considered one of Lisp's killer features. It's a shame they're inextricably linked to the syntax (or lack thereof) and that nobody has yet figured out a good macro system that doesn't depend on S-expressions.

Probably because Lisp is unusable without macros, sort of like how C and C++ are unusable without the preprocessor.

Lisp is a great language for its ideas, and is a fine language for research purposes. But somehow it just never catches on.

On 12/20/2018 11:23 PM, Manu wrote:
> I don't think I've ever wanted multiple inheritance in D,

That's what multiple alias this is.

> and occasionally multiple implicit conversions.

Another feature that looks great in the small, but turns into a hopeless morass all too quickly. Even C++ gave up on that, which meant it was pretty bad :-)

(Basically, nobody could figure out which overload was being called and why.)