Opportunities for D

Timon Gehr via Digitalmars-d digitalmars-d at puremagic.com
Wed Jul 9 20:12:23 PDT 2014


On 07/10/2014 02:39 AM, Walter Bright wrote:
> On 7/9/2014 5:24 PM, Timon Gehr wrote:
>> On 07/09/2014 09:50 PM, Walter Bright wrote:
>>> On 7/9/2014 7:37 AM, Timon Gehr wrote:
>>>> On 07/08/2014 11:22 PM, Walter Bright wrote:
>>>>> 3. 'ref' means 'borrowed', to use Rust's terminology
>>>>> We're almost there with this. This means better escape analysis, too.
>>>> What makes you think that 'ref' is a good match for this
>>>> functionality, and how
>>>> are we almost there with this?
>>>
>>> 'ref' is already used conventionally in such a manner as implying it is
>>> borrowed. 'ref' pointers cannot be stored,
>>
>> Borrowed pointers can be stored in data structures and they can be
>> reassigned.
>
> My purpose in posting this is not "I have a design". I don't have a
> design. A design needs to be created:
>
> 1. assess where we are

I think we are basically nowhere. Borrowing is about controlling lifetimes.

> 2. decide where we want to be

I don't know, but I assume it would have to be competitive with what 
Rust provides.

> 3. have a design and a plan that gets there
>
> There's no law that says D refs must be exactly like Rust borrowed. We
> can come up with a design that works best for D. D != Rust. Do you have
> a design in mind?
> ...

Roughly, but not with 'ref'. It is also an issue of syntax at this 
point. I think we should get at least the basics fixed there before 
talking in-depth about semantics. (In any case, I still have one DIP 
pending in an unacceptable state that I couldn't find the time to write 
down properly yet.)

Fundamentally, we need syntax for (examples provided for illustration, 
those are not proposals):

- Parametric polymorphism

Eg.: void foo[A](int x){ ... }


- Lifetime parameters. (it's more future-proof if they are not 
introduced by simple identifiers.)

Eg.: void foo[lifetime lt](int x){ ... }


- Attaching a lifetime to a pointer, class reference, ref argument.

Eg.: void foo[lifetime lt](int scope(lt)* x){ ...}
      void foo[lifetime lt](scope(lt) C c){ ... }
      void foo[lifetime lt](scope(lt) ref int x){ ... }
      void foo[lifetime lt1,lifetime lt2](scope(lt1)(C)scope(lt2)[] a){ 
... }

(The last example talks about a slice where the array memory has 
different lifetimes than the class instances it contains.)

- Lifetime intersection:

Eg.: scope(lt1&lt2)Tuple!(int*,int*) pair[lifetime lt1,lifetime lt2](int 
scope(lt1)* p1, int scope(lt1)* p2){ ... }

(It can alternatively be done only implicitly at function boundaries.)


- Specifying the lifetime of a struct/class upon construction:

Eg.: struct S[lifetime lt1,lifetime lt2]{
          ...
          this(int scope(lt1)* x, int scope(lt2)* y)scope(lt1&lt2){ ... }
      }

>...
>
>>>>> For those that want a non-nullable reference type. This should be
>>>>> doable
>>>>> as a library type.
>>>> No.
>>>
>>> Rationale?
>>
>> null
>
> ??

My point exactly. http://xkcd.com/641/

Also, there will be the usual problems with subtyping.


More information about the Digitalmars-d mailing list