On Tuesday, 1 April 2014 at 05:53:15 UTC, Walter Bright wrote:
> On 3/31/2014 10:02 PM, Manu wrote:
>> It's a really common pattern, it's obviously very useful, but it's surprising to
>> me that people think that it's like, 'cool'.
>> I get why it's done, and it's cool that D can do this (I use it a lot in my
>> code), but I don't feel it's particularly elegant.
>
> 'alias this' is inelegant (sorry Andrei) but it was designed for precisely this purpose - being able to use a struct to wrap any other type, and forward to and override behaviors of that type. Nobody has found a better way.

There's any plan for implementing the multiple alias this?
---
Paolo

On 4/1/2014 12:22 AM, Paolo Invernizzi wrote:
> There's any plan for implementing the multiple alias this?

It's a good idea, but it's a bit far down the list of what we simply must get done soon.

"Manu" <turkeyman@gmail.com> wrote in message news:mailman.122.1396231817.25518.digitalmars-d@puremagic.com...
> On 30 March 2014 13:39, Walter Bright <newshound2@digitalmars.com> wrote:
>>>
>>> Two pointers structs are passed in register, which is fast. If that
>>> spill, that
>>> spill on stack, which is hot, and prefetcher friendly.
>>>
>>
>> That underestimates how precious register real estate is on the x86.
>
>
> This is only a concern when passing args. x86 has huge internal register files and uses aggressive register renaming,

If we could use them that would be great but we cant. We have to store/load to memory, and that means aprox 3 cycle latency each way. The cpu cant guess that we're only saving it for later, it has to do the memory write, and even with the store to load forwarding mechanism, spilling and reloading is expensive.

On 1 April 2014 18:33, dajones <dajones@hotmail.com> wrote:

>
> "Manu" <turkeyman@gmail.com> wrote in message news:mailman.122.1396231817.25518.digitalmars-d@puremagic.com...
> > On 30 March 2014 13:39, Walter Bright <newshound2@digitalmars.com>
> wrote:
> >>>
> >>> Two pointers structs are passed in register, which is fast. If that
> >>> spill, that
> >>> spill on stack, which is hot, and prefetcher friendly.
> >>>
> >>
> >> That underestimates how precious register real estate is on the x86.
> >
> >
> > This is only a concern when passing args. x86 has huge internal register files and uses aggressive register renaming,
>
> If we could use them that would be great but we cant. We have to store/load
> to memory, and that means aprox 3 cycle latency each way. The cpu cant
> guess
> that we're only saving it for later, it has to do the memory write, and
> even
> with the store to load forwarding mechanism, spilling and reloading is
> expensive.
>

Can you detail this more?

Obviously it must perform the store to maintain memory coherency, but I was
under the impression that the typical implementation would also keep the
value around in a renamed register, and when it pops up again at a later
time, it would use the register directly, rather than load from memory.
The store shouldn't take any significant time since there's no dependency
on the stored value, it should only take as long as issuing the store
instruction; latency is irrelevant, since it's never read back, there's
nothing waiting on it.
Not sure what you mean by 'each way', since stored values shouldn't be read
back if gets the value from a stashed register.

I'm not an expert on the topic, but I read about it some years back, and haven't given it much thought since.

On 2014-04-01 05:39:04 +0000, Manu <turkeyman@gmail.com> said:

> The point is, it's impossible to bank on pointers being either 32 or 64
> bit. This leads to #ifdef's at the top of classes in my experience. D is
> not exempt.

Doesn't align(n) work for class members? If it does not, it doesn't seem it'd be hard to implement.

-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca

On 2014-04-01 07:11:51 +0000, Manu <turkeyman@gmail.com> said:

> Of course, I use alias this all the time too for various stuff. I said
> before, it's a useful tool and it's great D *can* do this stuff, but I'm
> talking about this particular super common use case where it's used to hack
> together nothing more than a class without a vtable, ie, a basic ref type.
> I'd say that's worth serious consideration as a 1st-class concept?

You don't need it as a 1st-class D concept though. Just implement the basics of the C++ object model in D, similar to what I did for Objective-C, and let people define their own extern(C++) classes with no base class. Bonus if it's binary compatible with the equivalent C++ class. Hasn't someone done that already?

-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca

"Michel Fortin"  wrote in message news:lhe9v8$28lp$1@digitalmars.com...

> You don't need it as a 1st-class D concept though. Just implement the basics of the C++ object model in D, similar to what I did for Objective-C, and let people define their own extern(C++) classes with no base class. Bonus if it's binary compatible with the equivalent C++ class. Hasn't someone done that already?

Mostly, but it will put out a vtbl even for classes with no virtual member functions. 

On 1 April 2014 21:50, Michel Fortin <michel.fortin@michelf.ca> wrote:

> On 2014-04-01 05:39:04 +0000, Manu <turkeyman@gmail.com> said:
>
>  The point is, it's impossible to bank on pointers being either 32 or 64
>> bit. This leads to #ifdef's at the top of classes in my experience. D is not exempt.
>>
>
> Doesn't align(n) work for class members? If it does not, it doesn't seem
> it'd be hard to implement.


The point is to eliminate the wasted padding by rearranging structure members appropriately. Since the amount of padding may be different between arch's, the layout often needs tweaking.

On 1 April 2014 22:03, Michel Fortin <michel.fortin@michelf.ca> wrote:

> On 2014-04-01 07:11:51 +0000, Manu <turkeyman@gmail.com> said:
>
>  Of course, I use alias this all the time too for various stuff. I said
>> before, it's a useful tool and it's great D *can* do this stuff, but I'm
>>
>> talking about this particular super common use case where it's used to
>> hack
>> together nothing more than a class without a vtable, ie, a basic ref type.
>> I'd say that's worth serious consideration as a 1st-class concept?
>>
>
> You don't need it as a 1st-class D concept though. Just implement the basics of the C++ object model in D, similar to what I did for Objective-C, and let people define their own extern(C++) classes with no base class. Bonus if it's binary compatible with the equivalent C++ class. Hasn't someone done that already?


I don't think the right conceptual solution to a general ref-type intended for use throughout D code is to mark it extern C++... That makes no sense.

I agree that current problems with defining performant reference types are very nasty. I disagree with conclusion that classes need to be made more lightweight though. What is really desired is good solution for defining own full-featured reference types instead. D classes and "performance" simply don't connect in my mind in a single use case.