digitalmars.D - change 'this' pointer for structs to reference type
- Walter Bright (6/6) Nov 02 2008 Andrei suggested this change, and I think it is a great idea. D ought to...
- Janderson (6/13) Nov 02 2008 I never understood why struct's in D worked this way. When I initially
- bearophile (6/10) Nov 02 2008 I think it doesn't matter, because D2 is already a different language.
- dsimcha (8/14) Nov 02 2008 I'd say go for it. I wouldn't be at all worried at this point about thi...
- Robert Fraser (3/10) Nov 02 2008 While we're at it, let's have "in" return a reference instead of a
- Andrei Alexandrescu (3/14) Nov 02 2008 Unfortunately that won't be possible because references can't be null.
- Robert Fraser (3/19) Nov 02 2008 Ah, I see. But then what about the "no pointers in SafeD" thing... does
- Jarrett Billingsley (32/54) Nov 02 2008 On-topic: I don't see any problem with changing struct 'this' to a
- Denis Koroskin (6/67) Nov 02 2008 I would drop the 'in' keyword altogether (opIn_r is horrible, imo).
- bearophile (10/12) Nov 02 2008 Okay, thank you all the people in this thread (Jarrett Billingsley too) ...
- Denis Koroskin (5/38) Nov 02 2008 It's just a matter of syntax. You don't loose an ability to use pointers...
- BCS (2/18) Nov 03 2008 without checking I'd say I as often as not do use the pointer from in.
- Andrei Alexandrescu (3/23) Nov 02 2008 It means we'll have to redesign "in".
- Jason House (2/16) Nov 02 2008 Us that true of class reference parameters to functions? I doubt it. I w...
- Denis Koroskin (5/11) Nov 02 2008 Could you please clarify what do you mean (I don't get it). Does this me...
- Frits van Bommel (4/18) Nov 02 2008 I think "typeof(this) == S*" is the current situation. What they're
- Walter Bright (2/4) Nov 02 2008 Not exactly, ref is not a type constructor. typeof(this)==S
- Frits van Bommel (2/7) Nov 02 2008 As long as it's still a reference, that's close enough for 'this' :).
- Denis Koroskin (5/11) Nov 02 2008 Will the following code:
- Walter Bright (2/6) Nov 02 2008 No, because new will still return a typeof(this)*.
- BCS (2/10) Nov 03 2008 In struct, yes, but not in classes I wouldn't think?
- Walter Bright (2/16) Nov 03 2008 Right, not for classes.
- Steven Schveighoffer (11/23) Nov 04 2008 This wouldn't work in today's compiler or tomorrow's.
- Moritz Warning (13/20) Nov 02 2008 It's not clear to me what the effect would be on the usage.
- Simen Kjaeraas (7/27) Nov 02 2008 You're somewhat off track. Foo foo = new Foo(); will not compile, as
- Moritz Warning (3/36) Nov 02 2008 Thanks.
- Denis Koroskin (8/41) Nov 02 2008 I'm not sure about this:
- Moritz Warning (3/39) Nov 02 2008 typeof(il) have to be int since opIndex returns int.
- Simen Kjaeraas (8/47) Nov 03 2008 'fraid not. foo1 would be of type Foo*, so foo1[42] would return
- Leandro Lucarella (15/21) Nov 05 2008 I saw you made some changes in phobos for this. But I think there is
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
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
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
== Quote from Walter Bright (newshound1 digitalmars.com)'s articleAndrei 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
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
Robert Fraser wrote:Walter Bright wrote:Unfortunately that won't be possible because references can't be null. AndreiAndrei 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
Andrei Alexandrescu wrote:Robert Fraser wrote:Ah, I see. But then what about the "no pointers in SafeD" thing... does this mean SafeD will also lack the "in" operator?Walter Bright wrote:Unfortunately that won't be possible because references can't be null. AndreiAndrei 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
On Sun, Nov 2, 2008 at 11:26 AM, Robert Fraser <fraserofthenight gmail.com> wrote:Andrei Alexandrescu wrote: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?Robert Fraser wrote:Ah, I see. But then what about the "no pointers in SafeD" thing... does this mean SafeD will also lack the "in" operator?Walter Bright wrote:Unfortunately that won't be possible because references can't be null. AndreiAndrei 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
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: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?).Andrei Alexandrescu wrote: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?Robert Fraser wrote:Ah, I see. But then what about the "no pointers in SafeD" thing... does this mean SafeD will also lack the "in" operator?Walter Bright wrote:Unfortunately that won't be possible because references can't be null. AndreiAndrei 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
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
On Sun, 02 Nov 2008 22:15:20 +0300, bearophile <bearophileHUGS lycos.com> wrote:Denis Koroskin: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?).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
Reply to Jarrett,On Sun, Nov 2, 2008 at 11:26 AM, Robert Fraser <fraserofthenight gmail.com> wrote:without checking I'd say I as often as not do use the pointer from in.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.
Nov 03 2008
Robert Fraser wrote:Andrei Alexandrescu wrote:It means we'll have to redesign "in". AndreiRobert Fraser wrote:Ah, I see. But then what about the "no pointers in SafeD" thing... does this mean SafeD will also lack the "in" operator?Walter Bright wrote:Unfortunately that won't be possible because references can't be null. AndreiAndrei 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
Andrei Alexandrescu Wrote:Robert Fraser wrote:Us that true of class reference parameters to functions? I doubt it. I would love to see nullable and non-nullable types in D.Walter Bright wrote:Unfortunately that won't be possible because references can't be null.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
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
Denis Koroskin wrote:On Sun, 02 Nov 2008 10:01:24 +0300, Walter Bright <newshound1 digitalmars.com> wrote: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.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
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
Walter Bright wrote:Frits van Bommel wrote:As long as it's still a reference, that's close enough for 'this' :).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
On Sun, 02 Nov 2008 21:59:50 +0300, Frits van Bommel <fvbommel remwovexcapss.nl> wrote:Walter Bright wrote:Will the following code: typeof(this) foo = new typeof(this); work as expected?Frits van Bommel wrote:As long as it's still a reference, that's close enough for 'this' :).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
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
Reply to Walter,Denis Koroskin wrote:In struct, yes, but not in classes I wouldn't think?Will the following code: typeof(this) foo = new typeof(this); work as expected?No, because new will still return a typeof(this)*.
Nov 03 2008
BCS wrote:Reply to Walter,Right, not for classes.Denis Koroskin wrote:In struct, yes, but not in classes I wouldn't think?Will the following code: typeof(this) foo = new typeof(this); work as expected?No, because new will still return a typeof(this)*.
Nov 03 2008
"Denis Koroskin" wroteOn Sun, 02 Nov 2008 21:59:50 +0300, Frits van Bommel <fvbommel remwovexcapss.nl> wrote: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. -SteveWalter Bright wrote:Will the following code: typeof(this) foo = new typeof(this); work as expected?Frits van Bommel wrote:As long as it's still a reference, that's close enough for 'this' :).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 04 2008
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
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: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. -- SimenAndrei 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
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:Thanks. It's a hassle to have to do (*foo)[42].On Sun, 02 Nov 2008 00:01:24 -0700, Walter Bright wrote: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.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
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: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.On Sun, 02 Nov 2008 00:01:24 -0700, Walter Bright wrote: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.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
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){} }typeof(il) have to be int since opIndex returns int.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
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:'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. -- SimenOn 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){} }typeof(il) have to be int since opIndex returns int.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 03 2008
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