change 'this' pointer for structs to reference type

[Jarrett Billingsley]

On Sun, Nov 2, 2008 at 11:26 AM, Robert Fraser
<fraserofthenight at 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?