Hiding class pointers -- was it a good idea?

[Jason House]

Bill Baxter wrote:
> Jason House wrote:
>> I was thinking recently of an interesting syntax twist...  Always 
>> require & when trying to get to an address, and use the raw variable 
>> name and "." to refer to whatever is pointed to.  Obtaining an address 
>> would require &.
>>
>> It's an interesting change, but would likely be too confusing to 
>> switch over.  Somehow I bet even suggesting the idea will mark me as a 
>> crack pot :)
> 
> Well realistically none of this is likely to change anyway, so you're 
> free to suggest anything you want.  :-)
> I was thinking about something like that as well, though.  But couldn't 
> really think how to make it useful.
> 
> My thinking was that in D we have classes sort of "shifted" by one from 
> structs
> 
>         pointer-to-pointer   pointer   value
> struct    &(&p)                &p        p
> struct*    &p                   p       *p
> class      &p                   p       N/A
> 
> So instead of that make structs default to pointers too, to shift 
> everything back to be the same:
> 
>         pointer-to-pointer   pointer   value
> struct#       &(&p)            &p        p
> struct        &p                p       *p
> class         &p                p       N/A

I was thinking of something more consistent.

         pointer-to-pointer   pointer   value
struct         N/A             &p        p
struct*        &&p             &p        p
class          &&p             &p        p
T              ???             &p        p


simply doing p will always give the value and &p will always give a 
pointer.  How many &'s allowed would be specific to the 
circumstance/implementation.  In my naive view, the last valid pointer 
(&p for struct, &&p for struct*, etc...) would have to be const.  T 
above is supposed to be some kind of templated type