change 'this' pointer for structs to reference type

[Denis Koroskin]

On Sun, 02 Nov 2008 19:51:27 +0300, Jarrett Billingsley  
<jarrett.billingsley at gmail.com> wrote:

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

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