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