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

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

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.

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){}
>>> }
>>>
[..]
>>
>>
> 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.

typeof(il) have to be int since opIndex returns int.

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){}
>>>> }
>>>>
> [..]
>>>
>>>
>> 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.
>
> 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

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

without checking I'd say I as often as not do use the pointer from in.

Reply to Walter,

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

In struct, yes, but not in classes I wouldn't think?

BCS wrote:
> Reply to Walter,
> 
>> 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)*.
>>
> 
> In struct, yes, but not in classes I wouldn't think?
> 
> 

Right, not for classes.

"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".
>>>  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' :).
>
> 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

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