www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - change 'this' pointer for structs to reference type

reply Walter Bright <newshound1 digitalmars.com> writes:
Andrei suggested this change, and I think it is a great idea. D ought to 
be moving away from pointers for routine work, and this would make a lot 
of sense.

It would entail some changes to user code, mostly when dealing with the 
opCmp and opEquals member functions. The function signatures for them 
would be changed to opCmp(ref const S).
Nov 02 2008
next sibling parent Janderson <ask me.com> writes:
Walter Bright wrote:
 Andrei suggested this change, and I think it is a great idea. D ought to 
 be moving away from pointers for routine work, and this would make a lot 
 of sense.
 
 It would entail some changes to user code, mostly when dealing with the 
 opCmp and opEquals member functions. The function signatures for them 
 would be changed to opCmp(ref const S).

I never understood why struct's in D worked this way. When I initially went to use D structs I assumed 'this' would behave in the same way as classes. Making 'this' a reference type for struct's makes sense to me. Of course it does mean another code breaking feature like you said. -Joel
Nov 02 2008
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:
 Andrei suggested this change, and I think it is a great idea. D ought to 
 be moving away from pointers for routine work, and this would make a lot 
 of sense.

I am not expert of C++ matters, but I think this is a change for the better.
 It would entail some changes to user code,

I think it doesn't matter, because D2 is already a different language. I instead encourage you to keep D2 design fluid still, allowing similar positive changes in other parts of the language still, because probably there are other things that can be improved. I don't know if D2-D3 will become widespread languages, but every time you improve something like this one programmer of the future will say a silent pray to thank you for a well designed "detail" :-) Bye, bearophile
Nov 02 2008
prev sibling next sibling parent dsimcha <dsimcha yahoo.com> writes:
== Quote from Walter Bright (newshound1 digitalmars.com)'s article
 Andrei suggested this change, and I think it is a great idea. D ought to
 be moving away from pointers for routine work, and this would make a lot
 of sense.
 It would entail some changes to user code, mostly when dealing with the
 opCmp and opEquals member functions. The function signatures for them
 would be changed to opCmp(ref const S).

I'd say go for it. I wouldn't be at all worried at this point about things that break code in trivial ways in the D2 branch. I write D2 code, and to me the advantages of having a well-thought-out language without any strange artifacts from the caveman era greatly outweigh the need to fix some trivially broken code every few releases. On the other hand, I'd obviously be more conservative about non-trivial changes that require redesign of parts of the code, now that D2 is getting close.
Nov 02 2008
prev sibling next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Walter Bright wrote:
 Andrei suggested this change, and I think it is a great idea. D ought to 
 be moving away from pointers for routine work, and this would make a lot 
 of sense.
 
 It would entail some changes to user code, mostly when dealing with the 
 opCmp and opEquals member functions. The function signatures for them 
 would be changed to opCmp(ref const S).

While we're at it, let's have "in" return a reference instead of a pointer for AAs.
Nov 02 2008
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Robert Fraser wrote:
 Walter Bright wrote:
 Andrei suggested this change, and I think it is a great idea. D ought 
 to be moving away from pointers for routine work, and this would make 
 a lot of sense.

 It would entail some changes to user code, mostly when dealing with 
 the opCmp and opEquals member functions. The function signatures for 
 them would be changed to opCmp(ref const S).

While we're at it, let's have "in" return a reference instead of a pointer for AAs.

Unfortunately that won't be possible because references can't be null. Andrei
Nov 02 2008
next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Andrei Alexandrescu wrote:
 Robert Fraser wrote:
 Walter Bright wrote:
 Andrei suggested this change, and I think it is a great idea. D ought 
 to be moving away from pointers for routine work, and this would make 
 a lot of sense.

 It would entail some changes to user code, mostly when dealing with 
 the opCmp and opEquals member functions. The function signatures for 
 them would be changed to opCmp(ref const S).

While we're at it, let's have "in" return a reference instead of a pointer for AAs.

Unfortunately that won't be possible because references can't be null. Andrei

Ah, I see. But then what about the "no pointers in SafeD" thing... does this mean SafeD will also lack the "in" operator?
Nov 02 2008
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Robert Fraser wrote:
 Andrei Alexandrescu wrote:
 Robert Fraser wrote:
 Walter Bright wrote:
 Andrei suggested this change, and I think it is a great idea. D 
 ought to be moving away from pointers for routine work, and this 
 would make a lot of sense.

 It would entail some changes to user code, mostly when dealing with 
 the opCmp and opEquals member functions. The function signatures for 
 them would be changed to opCmp(ref const S).

While we're at it, let's have "in" return a reference instead of a pointer for AAs.

Unfortunately that won't be possible because references can't be null. Andrei

Ah, I see. But then what about the "no pointers in SafeD" thing... does this mean SafeD will also lack the "in" operator?

It means we'll have to redesign "in". Andrei
Nov 02 2008
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Denis Koroskin:
 I would drop the 'in' keyword altogether (opIn_r is horrible, imo).
 I believe 'lookup' or 'find' methods are generally better.

Okay, thank you all the people in this thread (Jarrett Billingsley too) for helping me see things better. Dropping "in" for AAs? That's mad. Or making it return a boolean like in Python? but D isn't Python. I don't want Python here, I already have Python elsewhere. Removing something from D2 because of SafeD? What? I don't like to change D2 to suit SafeD (if safeD is wanted then you have to think of it as another language with few differences, like the semantics of "in" that returns a bool in safeD and returns a pointer in D2). Now I think "in" is fine as it is. I like pointers to refer to structs. I like none of the proposed changes :-) The point of having a system language is to have a language that allows me to be efficient, avoiding unnecessary AA lookups, and to use pointers without doing strange things, and especially to have ways to control memory exactly, so if I want a struct of 6 bytes I want it (D1 already doesn't work fully this way, because the allocator allocates at powers of two sizes and that's barely acceptable). If you make D2 become something different from a system language some people will have to work hard to invent yet another language (D1? C2?) to replace it. Pointers are dangerous, and I don't want to use them to use strings, arrays, etc etc. But I don't like the idea of having to cast a struct reference when I want to use them. Having control over how the memory is used and how pointers are manages is probably the only real advantage the D1 language has over Java (No, speed isn't an advantage, because you can see that in practice HotSpot produces code that is often faster than programs compiled with DMD for D1). So if you remove such things D2 becomes quite less useful. Bye, bearophile
Nov 02 2008
prev sibling parent Jason House <jason.james.house gmail.com> writes:
Andrei Alexandrescu Wrote:

 Robert Fraser wrote:
 Walter Bright wrote:
 Andrei suggested this change, and I think it is a great idea. D ought 
 to be moving away from pointers for routine work, and this would make 
 a lot of sense.

 It would entail some changes to user code, mostly when dealing with 
 the opCmp and opEquals member functions. The function signatures for 
 them would be changed to opCmp(ref const S).

While we're at it, let's have "in" return a reference instead of a pointer for AAs.

Unfortunately that won't be possible because references can't be null.

Us that true of class reference parameters to functions? I doubt it. I would love to see nullable and non-nullable types in D.
Nov 02 2008
prev sibling next sibling parent reply "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Sun, Nov 2, 2008 at 11:26 AM, Robert Fraser
<fraserofthenight gmail.com> wrote:
 Andrei Alexandrescu wrote:
 Robert Fraser wrote:
 Walter Bright wrote:
 Andrei suggested this change, and I think it is a great idea. D ought to
 be moving away from pointers for routine work, and this would make a lot of
 sense.

 It would entail some changes to user code, mostly when dealing with the
 opCmp and opEquals member functions. The function signatures for them would
 be changed to opCmp(ref const S).

While we're at it, let's have "in" return a reference instead of a pointer for AAs.

Unfortunately that won't be possible because references can't be null. Andrei

Ah, I see. But then what about the "no pointers in SafeD" thing... does this mean SafeD will also lack the "in" operator?

On-topic: I don't see any problem with changing struct 'this' to a reference type. What happens to the "null this" check, though? Somewhat off-topic: Here's a crazy idea - get rid of the bizarre 'in' operator altogether since what it does can be done better with a library function (or multiple functions for different behaviors). Why do you need a pointer from 'in' anyway? To avoid a double lookup, yes, but what do you use the 'in' operator for? Most of the time I'm not using it to test if something's in the AA. I'm using it to perform a non-exception-throwing lookup. So I suggest that 'in' becomes a simple "is x in y?" test that always returns a bool. This also makes it very easy to implement the oft-requested !in operator, as there is no longer any asymmetry. It then _also_ makes sense to implement the oft-requested "x in array" functionality. The current behavior of 'in' for associative arrays (which, I remind you, is the only type in the language for which 'in' is defined by default in the first place) can be just as well covered by a library function. Something like "V* lookup(K, V)(V[K] aa, K key)" would behave just like 'in' does currently: int[int] aa = ...; if(auto val = aa.lookup(5)) // use *val here But it still has the problem that it wouldn't be usable from SafeD. Something like "bool lookup(K, V)(V[K] aa, K key, out V val)" would be usable from SafeD at the cost of being a bit more verbose: int[int] aa = ...; int val; if(aa.lookup(5, val)) // use val here Thoughts?
Nov 02 2008
parent BCS <ao pathlink.com> writes:
Reply to Jarrett,

 On Sun, Nov 2, 2008 at 11:26 AM, Robert Fraser
 <fraserofthenight gmail.com> wrote:
 Ah, I see. But then what about the "no pointers in SafeD" thing...
 does this mean SafeD will also lack the "in" operator?
 

reference type. What happens to the "null this" check, though? Somewhat off-topic: Here's a crazy idea - get rid of the bizarre 'in' operator altogether since what it does can be done better with a library function (or multiple functions for different behaviors). Why do you need a pointer from 'in' anyway? To avoid a double lookup, yes, but what do you use the 'in' operator for? Most of the time I'm not using it to test if something's in the AA. I'm using it to perform a non-exception-throwing lookup.

without checking I'd say I as often as not do use the pointer from in.
Nov 03 2008
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Sun, 02 Nov 2008 19:51:27 +0300, Jarrett Billingsley  
<jarrett.billingsley gmail.com> wrote:

 On Sun, Nov 2, 2008 at 11:26 AM, Robert Fraser
 <fraserofthenight gmail.com> wrote:
 Andrei Alexandrescu wrote:
 Robert Fraser wrote:
 Walter Bright wrote:
 Andrei suggested this change, and I think it is a great idea. D  
 ought to
 be moving away from pointers for routine work, and this would make a  
 lot of
 sense.

 It would entail some changes to user code, mostly when dealing with  
 the
 opCmp and opEquals member functions. The function signatures for  
 them would
 be changed to opCmp(ref const S).

While we're at it, let's have "in" return a reference instead of a pointer for AAs.

Unfortunately that won't be possible because references can't be null. Andrei

Ah, I see. But then what about the "no pointers in SafeD" thing... does this mean SafeD will also lack the "in" operator?

On-topic: I don't see any problem with changing struct 'this' to a reference type. What happens to the "null this" check, though? Somewhat off-topic: Here's a crazy idea - get rid of the bizarre 'in' operator altogether since what it does can be done better with a library function (or multiple functions for different behaviors). Why do you need a pointer from 'in' anyway? To avoid a double lookup, yes, but what do you use the 'in' operator for? Most of the time I'm not using it to test if something's in the AA. I'm using it to perform a non-exception-throwing lookup. So I suggest that 'in' becomes a simple "is x in y?" test that always returns a bool. This also makes it very easy to implement the oft-requested !in operator, as there is no longer any asymmetry. It then _also_ makes sense to implement the oft-requested "x in array" functionality. The current behavior of 'in' for associative arrays (which, I remind you, is the only type in the language for which 'in' is defined by default in the first place) can be just as well covered by a library function. Something like "V* lookup(K, V)(V[K] aa, K key)" would behave just like 'in' does currently: int[int] aa = ...; if(auto val = aa.lookup(5)) // use *val here But it still has the problem that it wouldn't be usable from SafeD. Something like "bool lookup(K, V)(V[K] aa, K key, out V val)" would be usable from SafeD at the cost of being a bit more verbose: int[int] aa = ...; int val; if(aa.lookup(5, val)) // use val here Thoughts?

I would drop the 'in' keyword altogether (opIn_r is horrible, imo). I believe 'lookup' or 'find' methods are generally better. Besides, returning the pointer doesn't fit the range idiom (why doesn't foo in aa return range?).
Nov 02 2008
prev sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Sun, 02 Nov 2008 22:15:20 +0300, bearophile <bearophileHUGS lycos.com>  
wrote:

 Denis Koroskin:
 I would drop the 'in' keyword altogether (opIn_r is horrible, imo).
 I believe 'lookup' or 'find' methods are generally better.

Okay, thank you all the people in this thread (Jarrett Billingsley too) for helping me see things better. Dropping "in" for AAs? That's mad. Or making it return a boolean like in Python? but D isn't Python. I don't want Python here, I already have Python elsewhere. Removing something from D2 because of SafeD? What? I don't like to change D2 to suit SafeD (if safeD is wanted then you have to think of it as another language with few differences, like the semantics of "in" that returns a bool in safeD and returns a pointer in D2). Now I think "in" is fine as it is. I like pointers to refer to structs. I like none of the proposed changes :-) The point of having a system language is to have a language that allows me to be efficient, avoiding unnecessary AA lookups, and to use pointers without doing strange things, and especially to have ways to control memory exactly, so if I want a struct of 6 bytes I want it (D1 already doesn't work fully this way, because the allocator allocates at powers of two sizes and that's barely acceptable). If you make D2 become something different from a system language some people will have to work hard to invent yet another language (D1? C2?) to replace it. Pointers are dangerous, and I don't want to use them to use strings, arrays, etc etc. But I don't like the idea of having to cast a struct reference when I want to use them. Having control over how the memory is used and how pointers are manages is probably the only real advantage the D1 language has over Java (No, speed isn't an advantage, because you can see that in practice HotSpot produces code that is often faster than programs compiled with DMD for D1). So if you remove such things D2 becomes quite less useful. Bye, bearophile

It's just a matter of syntax. You don't loose an ability to use pointers, just make your lookup/find method return pointer (but what's the point of this?).
Nov 02 2008
prev sibling next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Sun, 02 Nov 2008 10:01:24 +0300, Walter Bright  
<newshound1 digitalmars.com> wrote:

 Andrei suggested this change, and I think it is a great idea. D ought to  
 be moving away from pointers for routine work, and this would make a lot  
 of sense.

 It would entail some changes to user code, mostly when dealing with the  
 opCmp and opEquals member functions. The function signatures for them  
 would be changed to opCmp(ref const S).

Could you please clarify what do you mean (I don't get it). Does this mean that all structs are heap-allocated by default? Or typeof(this) == S* or what?
Nov 02 2008
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Denis Koroskin wrote:
 On Sun, 02 Nov 2008 10:01:24 +0300, Walter Bright 
 <newshound1 digitalmars.com> wrote:
 
 Andrei suggested this change, and I think it is a great idea. D ought 
 to be moving away from pointers for routine work, and this would make 
 a lot of sense.

 It would entail some changes to user code, mostly when dealing with 
 the opCmp and opEquals member functions. The function signatures for 
 them would be changed to opCmp(ref const S).

Could you please clarify what do you mean (I don't get it). Does this mean that all structs are heap-allocated by default? Or typeof(this) == S* or what?

I think "typeof(this) == S*" is the current situation. What they're suggesting is "typeof(this) == ref S". It has my vote, by the way.
Nov 02 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Frits van Bommel wrote:
 I think "typeof(this) == S*" is the current situation. What they're 
 suggesting is "typeof(this) == ref S".

Not exactly, ref is not a type constructor. typeof(this)==S
Nov 02 2008
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Walter Bright wrote:
 Frits van Bommel wrote:
 I think "typeof(this) == S*" is the current situation. What they're 
 suggesting is "typeof(this) == ref S".

Not exactly, ref is not a type constructor. typeof(this)==S

As long as it's still a reference, that's close enough for 'this' :).
Nov 02 2008
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Denis Koroskin wrote:
 Will the following code:
 typeof(this) foo = new typeof(this);
 
 work as expected?

No, because new will still return a typeof(this)*.
Nov 02 2008
parent reply BCS <ao pathlink.com> writes:
Reply to Walter,

 Denis Koroskin wrote:
 
 Will the following code:
 typeof(this) foo = new typeof(this);
 work as expected?
 


In struct, yes, but not in classes I wouldn't think?
Nov 03 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
BCS wrote:
 Reply to Walter,
 
 Denis Koroskin wrote:

 Will the following code:
 typeof(this) foo = new typeof(this);
 work as expected?


In struct, yes, but not in classes I wouldn't think?

Right, not for classes.
Nov 03 2008
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Denis Koroskin" wrote
 On Sun, 02 Nov 2008 21:59:50 +0300, Frits van Bommel 
 <fvbommel remwovexcapss.nl> wrote:

 Walter Bright wrote:
 Frits van Bommel wrote:
 I think "typeof(this) == S*" is the current situation. What they're 
 suggesting is "typeof(this) == ref S".


As long as it's still a reference, that's close enough for 'this' :).

Will the following code: typeof(this) foo = new typeof(this); work as expected?

This wouldn't work in today's compiler or tomorrow's. What this translates to in today's compiler is: S* foo = new S*; new S* should return an S**, so this should fail. with the proposed change you get: S foo = new S; new S should return an S*, so this should fail. It is only classes which would work with the given code, and that won't change. -Steve
Nov 04 2008
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Sun, 02 Nov 2008 21:59:50 +0300, Frits van Bommel  
<fvbommel remwovexcapss.nl> wrote:

 Walter Bright wrote:
 Frits van Bommel wrote:
 I think "typeof(this) == S*" is the current situation. What they're  
 suggesting is "typeof(this) == ref S".


As long as it's still a reference, that's close enough for 'this' :).

Will the following code: typeof(this) foo = new typeof(this); work as expected?
Nov 02 2008
prev sibling next sibling parent reply Moritz Warning <moritzwarning web.de> writes:
On Sun, 02 Nov 2008 00:01:24 -0700, Walter Bright wrote:

 Andrei suggested this change, and I think it is a great idea. D ought to
 be moving away from pointers for routine work, and this would make a lot
 of sense.
 
 It would entail some changes to user code, mostly when dealing with the
 opCmp and opEquals member functions. The function signatures for them
 would be changed to opCmp(ref const S).

It's not clear to me what the effect would be on the usage. struct Foo { int OpIndex(size_t){} } Foo foo = new Foo(); foo[42]; Could we do call opIndex now because this of Foo is a reference? It would be nice. But it might be "ref Foo foo = new Foo();" because it bites "Foo foo;" otherwise. Or am I off the track?
Nov 02 2008
next sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Sun, 02 Nov 2008 20:26:23 +0100, Moritz Warning <moritzwarning web.de>  
wrote:

 On Sun, 02 Nov 2008 00:01:24 -0700, Walter Bright wrote:

 Andrei suggested this change, and I think it is a great idea. D ought to
 be moving away from pointers for routine work, and this would make a lot
 of sense.

 It would entail some changes to user code, mostly when dealing with the
 opCmp and opEquals member functions. The function signatures for them
 would be changed to opCmp(ref const S).

It's not clear to me what the effect would be on the usage. struct Foo { int OpIndex(size_t){} } Foo foo = new Foo(); foo[42]; Could we do call opIndex now because this of Foo is a reference? It would be nice. But it might be "ref Foo foo = new Foo();" because it bites "Foo foo;" otherwise. Or am I off the track?

You're somewhat off track. Foo foo = new Foo(); will not compile, as new Foo would still return a Foo*. auto foo = new Foo(); foo[42]; would work, though. -- Simen
Nov 02 2008
prev sibling next sibling parent Moritz Warning <moritzwarning web.de> writes:
On Sun, 02 Nov 2008 21:03:26 +0100, Simen Kjaeraas wrote:

 On Sun, 02 Nov 2008 20:26:23 +0100, Moritz Warning
 <moritzwarning web.de> wrote:
 
 On Sun, 02 Nov 2008 00:01:24 -0700, Walter Bright wrote:

 Andrei suggested this change, and I think it is a great idea. D ought
 to be moving away from pointers for routine work, and this would make
 a lot of sense.

 It would entail some changes to user code, mostly when dealing with
 the opCmp and opEquals member functions. The function signatures for
 them would be changed to opCmp(ref const S).

It's not clear to me what the effect would be on the usage. struct Foo { int OpIndex(size_t){} } Foo foo = new Foo(); foo[42]; Could we do call opIndex now because this of Foo is a reference? It would be nice. But it might be "ref Foo foo = new Foo();" because it bites "Foo foo;" otherwise. Or am I off the track?

You're somewhat off track. Foo foo = new Foo(); will not compile, as new Foo would still return a Foo*. auto foo = new Foo(); foo[42]; would work, though.

Thanks. It's a hassle to have to do (*foo)[42].
Nov 02 2008
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Sun, 02 Nov 2008 23:03:26 +0300, Simen Kjaeraas  
<simen.kjaras gmail.com> wrote:

 On Sun, 02 Nov 2008 20:26:23 +0100, Moritz Warning  
 <moritzwarning web.de> wrote:

 On Sun, 02 Nov 2008 00:01:24 -0700, Walter Bright wrote:

 Andrei suggested this change, and I think it is a great idea. D ought  
 to
 be moving away from pointers for routine work, and this would make a  
 lot
 of sense.

 It would entail some changes to user code, mostly when dealing with the
 opCmp and opEquals member functions. The function signatures for them
 would be changed to opCmp(ref const S).

It's not clear to me what the effect would be on the usage. struct Foo { int OpIndex(size_t){} } Foo foo = new Foo(); foo[42]; Could we do call opIndex now because this of Foo is a reference? It would be nice. But it might be "ref Foo foo = new Foo();" because it bites "Foo foo;" otherwise. Or am I off the track?

You're somewhat off track. Foo foo = new Foo(); will not compile, as new Foo would still return a Foo*. auto foo = new Foo(); foo[42]; would work, though.

I'm not sure about this: auto foo1 = new Foo(); auto i1 = foo1[42]; // what is typeof(i1)? auto foo2 = new Foo[100]; auto i2 = foo2[42]; // what is typeof(i2)? I expect to see Foo in both cases.
Nov 02 2008
prev sibling next sibling parent Moritz Warning <moritzwarning web.de> writes:
On Mon, 03 Nov 2008 00:17:47 +0300, Denis Koroskin wrote:

 On Sun, 02 Nov 2008 23:03:26 +0300, Simen Kjaeraas
 <simen.kjaras gmail.com> wrote:
 
 On Sun, 02 Nov 2008 20:26:23 +0100, Moritz Warning
 <moritzwarning web.de> wrote:

 On Sun, 02 Nov 2008 00:01:24 -0700, Walter Bright wrote:

 Andrei suggested this change, and I think it is a great idea. D ought
 to
 be moving away from pointers for routine work, and this would make a
 lot
 of sense.

 It would entail some changes to user code, mostly when dealing with
 the opCmp and opEquals member functions. The function signatures for
 them would be changed to opCmp(ref const S).

It's not clear to me what the effect would be on the usage. struct Foo { int OpIndex(size_t){} }




auto foo1 = new Foo(); auto i1 = foo1[42]; // what is typeof(i1)? auto foo2 = new Foo[100]; auto i2 = foo2[42]; // what is typeof(i2)? I expect to see Foo in both cases.

typeof(il) have to be int since opIndex returns int.
Nov 02 2008
prev sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Mon, 03 Nov 2008 00:15:48 +0100, Moritz Warning <moritzwarning web.de>  
wrote:

 On Mon, 03 Nov 2008 00:17:47 +0300, Denis Koroskin wrote:

 On Sun, 02 Nov 2008 23:03:26 +0300, Simen Kjaeraas
 <simen.kjaras gmail.com> wrote:

 On Sun, 02 Nov 2008 20:26:23 +0100, Moritz Warning
 <moritzwarning web.de> wrote:

 On Sun, 02 Nov 2008 00:01:24 -0700, Walter Bright wrote:

 Andrei suggested this change, and I think it is a great idea. D ought
 to
 be moving away from pointers for routine work, and this would make a
 lot
 of sense.

 It would entail some changes to user code, mostly when dealing with
 the opCmp and opEquals member functions. The function signatures for
 them would be changed to opCmp(ref const S).

It's not clear to me what the effect would be on the usage. struct Foo { int OpIndex(size_t){} }




auto foo1 = new Foo(); auto i1 = foo1[42]; // what is typeof(i1)? auto foo2 = new Foo[100]; auto i2 = foo2[42]; // what is typeof(i2)? I expect to see Foo in both cases.

typeof(il) have to be int since opIndex returns int.

'fraid not. foo1 would be of type Foo*, so foo1[42] would return cast(Foo)(*(foo1 + 42 * Foo.sizeof)). So in both cases, the return value would be of type Foo. -- Simen
Nov 03 2008
prev sibling parent Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el  2 de noviembre a las 00:01 me escribiste:
 Andrei suggested this change, and I think it is a great idea. D ought to be 
 moving away from pointers for routine work, and this would make a lot of sense.
 
 It would entail some changes to user code, mostly when dealing with the opCmp
and 
 opEquals member functions. The function signatures for them would be changed
to 
 opCmp(ref const S).

I saw you made some changes in phobos for this. But I think there is a mistake in changeset 866[1]. I think the file trunk/phobos/std/string.d was not supposed to be commited, because it moves back from onRangeError to onArrayBoundsError, which was changed in the previous commit (and it's totally unreleated to the *this -> this change =). [1] http://www.dsource.org/projects/phobos/changeset/866 -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- Borrowing money from a friend is like having sex. It just completely changes the relationship. -- George Constanza
Nov 05 2008