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

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.

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.

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

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

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

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?

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?

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

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