www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Will D ever get a reference type?

reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Will D ever get a reference type?

I don't think pointers are really sufficient.
The handy 'foo.bar' == '(*foo).bar' attribute access is nice, but it 
doesn't allow you to really manipulate values and pointers to values 
interchangeably.

For instance, if I have an int pointer, x,  I can't do  (12 + x * 2) and 
  get integer math.  I get pointer math (if not an error).

--bb
Jul 27 2007
next sibling parent reply BCS <ao pathlink.com> writes:
Reply to Bill,

 Will D ever get a reference type?
 
 I don't think pointers are really sufficient.
 The handy 'foo.bar' == '(*foo).bar' attribute access is nice, but it
 doesn't allow you to really manipulate values and pointers to values
 interchangeably.
 For instance, if I have an int pointer, x,  I can't do  (12 + x * 2)
 and
 get integer math.  I get pointer math (if not an error).
 --bb
 

is the ref argument type more along the lines you are looking for? void Foo(ref int a) I know this is limited to arguments but other than that...
Jul 27 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
BCS wrote:
 Reply to Bill,
 
 Will D ever get a reference type?

 I don't think pointers are really sufficient.
 The handy 'foo.bar' == '(*foo).bar' attribute access is nice, but it
 doesn't allow you to really manipulate values and pointers to values
 interchangeably.
 For instance, if I have an int pointer, x,  I can't do  (12 + x * 2)
 and
 get integer math.  I get pointer math (if not an error).
 --bb

is the ref argument type more along the lines you are looking for? void Foo(ref int a) I know this is limited to arguments but other than that...

Yep, exactly like in the argument, but something that's return-able as well. --bb
Jul 28 2007
parent reply BCS <ao pathlink.com> writes:
Reply to Bill,

 BCS wrote:
 
 Reply to Bill,
 
 Will D ever get a reference type?
 
 I don't think pointers are really sufficient.
 The handy 'foo.bar' == '(*foo).bar' attribute access is nice, but it
 doesn't allow you to really manipulate values and pointers to values
 interchangeably.
 For instance, if I have an int pointer, x,  I can't do  (12 + x * 2)
 and
 get integer math.  I get pointer math (if not an error).
 --bb

void Foo(ref int a) I know this is limited to arguments but other than that...


<Nods>
 but something that's return-able as
 well.
 

that's worth thinking about the effects of
 --bb
 

Jul 29 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
BCS wrote:
 Reply to Bill,
 
 BCS wrote:

 Reply to Bill,

 Will D ever get a reference type?

 I don't think pointers are really sufficient.
 The handy 'foo.bar' == '(*foo).bar' attribute access is nice, but it
 doesn't allow you to really manipulate values and pointers to values
 interchangeably.
 For instance, if I have an int pointer, x,  I can't do  (12 + x * 2)
 and
 get integer math.  I get pointer math (if not an error).
 --bb

void Foo(ref int a) I know this is limited to arguments but other than that...


<Nods>
 but something that's return-able as
 well.

that's worth thinking about the effects of
 --bb


One interaction is that all the D substitutes for returnable reference types become somewhat redundant. Like for property syntax: class Foo { ref int prop() { return _prop; } ref int prop(int x) { return _prop = x; } private: int _prop; } foo.prop = 10 could now be implemented by the compiler either as getter followed by assigning to the ref, or by calling the setter. I haven't really been able to think of a case where a reference type per-se is absolutely essential, which is one reason why I asked the question. But I think what *is* absolutely essential is a way to return some sort of proxy that acts just like a Foo but in fact is really only a go-between for a Foo. References are in one sense just really dumb proxies that can't do anything but blindly forward requests unmodified directly to the object being proxied. They give anyone direct, unprotected access to the underlying object's state, which is usually not desirable in terms of encapsulation. So in C++ some folks say you should never return a reference to a member. If you're doing that you might as well have people access the member directly because once you return the reference you have no control over what the caller does to it, and have no way of knowing if or when they modify it. I posit that what you really want most of the time is to return something to the caller that acts just like a Foo, but still gives you some control, perhaps in the form of preventing certain operations, and/or giving you a way to observe modifications. References and const references are like simple proxies with the rules "you can do anything" and "you can do anything involving read-only operations". Well, that's about all the time I have for thinking about it right now. But I'm starting to think that reference types aren't necessary as long as you have an semi-efficient way to wrap *any* type with an object that can act just like it. I think somebody has been talking about trying to implement such a thing recently, but I can't recall who. --bb
Jul 29 2007
next sibling parent Manfred Nowak <svv1999 hotmail.com> writes:
Bill Baxter wrote

 I think somebody has been talking about 
 trying to implement such a thing recently, but I can't recall who.

Its one of the goals of drokue. -manfred
Jul 29 2007
prev sibling parent BCS <ao pathlink.com> writes:
Reply to Bill,

 I posit that what you really want most of the time is to return
 something to the caller that acts just like a Foo, but still gives you
 some control, perhaps in the form of preventing certain operations,
 and/or giving you a way to observe modifications.

if typedef's could overload opXxx functions then they could serve as the restriction proxy (just making up a syntax here) |template Range(int min, int max) |{ | typedef int Range | { | ref Range opAssign(int i) | { | if(min > i || max < i) throw new RangeError(); | super = i; | } | } |} | |class C |{ | int i; | | ref Range!(5, 12) getRef(){return i;} |} | |class C; |c.getRef = 14; // fails this would all be done at compile time
Jul 30 2007
prev sibling parent reply Nick Sabalausky <a a.a> writes:
You know you can just dereference the pointer like (12 + *x * 2), right? (Sorry
if you already did). Or are you saying you don't like needing to dereference it
like that?

Bill Baxter Wrote:

 Will D ever get a reference type?
 
 I don't think pointers are really sufficient.
 The handy 'foo.bar' == '(*foo).bar' attribute access is nice, but it 
 doesn't allow you to really manipulate values and pointers to values 
 interchangeably.
 
 For instance, if I have an int pointer, x,  I can't do  (12 + x * 2) and 
   get integer math.  I get pointer math (if not an error).
 
 --bb

Jul 27 2007
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
 Bill Baxter Wrote:
 
 Will D ever get a reference type?

 I don't think pointers are really sufficient.
 The handy 'foo.bar' == '(*foo).bar' attribute access is nice, but it 
 doesn't allow you to really manipulate values and pointers to values 
 interchangeably.

 For instance, if I have an int pointer, x,  I can't do  (12 + x * 2) and 
   get integer math.  I get pointer math (if not an error).


Nick Sabalausky wrote:
 You know you can just dereference the pointer like (12 + *x * 2), 

needing to dereference it like that?

The latter. D does go out of its way to try to remove the need for reference types ('.' can dereference a pointer, and opIndexAssign handles the a[i]=5), but there are still things you can't do. Like implement op-increment indexing operators for a class/struct: a[i]+=5; a[i]-=5; a[i]*=5; a[i]/=5; a[i]++; a[i]--; ... Or pass the result of a.opIndex(i) to a function that modifies the argument: setValue(a[i]) //calling void setValue(ref int i) This means it's not possible to create an array-like class that's truly interchangeable with the built-in arrays. It also affects properties. If there were reference types then it would be possible (though some would argue not advisable) to have the op-increment work for property methods: a.x += 5; where x is a member function like: ref int x() { return my_x; } So really what I was wondering is if Walter considers D's current pointers plus reference parameters to be enough. Are there any other things you can't currently do in D that reference types would allow? --bb
Jul 28 2007