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).

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

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

== 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.

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.

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

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 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?

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?).

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?