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