Hiding class pointers -- was it a good idea?

[Russell Lewis]

Bill Baxter wrote:
> Jason House wrote:
>> Bill Baxter wrote:
>>> I'm starting to seriously wonder if it was a good idea to hide the 
>>> pointers to classes.  It seemed kinda neat when I was first using D 
>>> that I could avoid typing *s all the time.  But as time wears on it's 
>>> starting to seem more like a liability.
>>
>>
>> The simple distinction between reference types and value types has 
>> irked me from the very beginning.  As a programmer using something 
>> that somebody else wrote, I shouldn't have to know its storage type. 
>> Distinctions between the two pop up here and there throughout D code. 
>> For example, value_type[] and ref_type[] have completely different 
>> copy behaviors.
>>
>>
>>>
>>> Bad points:
>>> - Harder to tell whether you're dealing with a pointer or not
>>>   (c.f. the common uninitialized 'MyObject obj;' bug)
>>> - To build on the stack, have to use 'scope'
>>>
>>> Good points:
>>> + No need to type '*' everywhere when you use class objects
>>> + ??? anything else ???
>>
>>
>> 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
> 
> '#' (or whatever -- perhaps re-use 'scope') becomes the "by value" 
> indicator.  So to do a struct-by-value you'd declare:
> 
>   MyStruct# Foo;
> 
> while
>   MyStruct Bar;
> 
> would be a pointer/reference just like MyClass is.
> 
> Some problems are:
> - what do you do about built-in value types like 'int'?  Doesn't make 
> sense to make 'int x' be a pointer type, IMHO.  And if the built-in 
> types behave differently from structs have you gained much?
> - for structs, as-value should be the common case, so you'll have to use 
> a '#' most every time you use a struct.
> - it still won't make the struct -> class transition all that much 
> easier unless classes gain the ability to be passed around by value.

It also doesn't help clarity (completely) because you can still have 
typedefs and other user-defined types that would have value semantics.