An important potential change to the language: transitory ref

[Andrei Alexandrescu]

On 03/20/2010 07:04 AM, Steven Schveighoffer wrote:
> Andrei Alexandrescu Wrote:
[snip]
>> My response to the above issue is two-pronged:
>>
>> (a) For List a class would be an alternative
>
> Note, this is impractical if you care about performance (I know,
> because originally, dcollections used classes for link nodes).

I agree :o).

>> (b) To work with pointers to structs use static member functions
>> and pointers instead of methods and references
>
> This prevents something like a linked list from being used in safe D.
> That might be too much of a restriction.  Yes, it makes code safer,
> but it makes safe D unusable.

Actually, no. Walter's vision is to enable certain pointer uses in 
SafeD. Unchecked pointer arithmetic is disabled, but code like the one 
below is entirely safe:

List * lst = new List;
List * lst2 = prepend(lst, new List);

In fact, restricting use of ref is beneficial for SafeD because it helps 
the static proof that any pointer in SafeD points to the 
garbage-collected heap (as opposed to e.g. dangling stack variables).

>> In an ideal world, if you have your hands on a pointer to a struct,
>> you should be reasonably certain that that lives on the heap. It
>> would be just great if D could guarantee that.
>
> again, not in safe D.  Anytime pointers enter the mix, safe D is
> disqualified, no?

As mentioned above, pointers are still on the table in SafeD. I found 
that quite interesting myself :o).

>> Your idea is good, except I don't see why not make ref scoped ref.
>> After all ref is currently not an enabler - it could be missing
>> from the language; pointers are fine. So why not make ref do
>> something actually interesting?
>
> The whole point was to run an experiment seeing how many things could
> be written as scoped ref instead of just ref (leaving ref the way it
> is today).  If they all can with minor adjustments, then we can
> switch scoped ref to simply ref.  If some can't, and those also don't
> make sense as pointers, then we have a predicament that ref enables
> some sort of code that isn't enabled by pointers or scoped ref.  My
> point was, I don't really know off the top of my head all the cases
> for using ref, and you probably don't either.  I don't think a
> sweeping change like this is good without at least some practical
> evidence.

That is very sensible, thanks.


Andrei