On Friday, 12 August 2016 at 12:29:21 UTC, Andrei Alexandrescu wrote:
> On 8/12/16 6:12 AM, deadalnix wrote:
>> To be honest I'm to a point were I'm starting withdrawing from these
>> conversation because I have no idea how to reach to you guys.
>
> You committed to author a proposal a few months back. Did you make progress on that? -- Andrei

Are you referring to this one?

https://github.com/dlang/DIPs/pull/16

On 8/12/16 6:12 AM, deadalnix wrote:
> To be honest I'm to a point were I'm starting withdrawing from these
> conversation because I have no idea how to reach to you guys.

You committed to author a proposal a few months back. Did you make progress on that? -- Andrei

On 8/12/16 8:28 AM, Seb wrote:
> On Friday, 12 August 2016 at 12:29:21 UTC, Andrei Alexandrescu wrote:
>> On 8/12/16 6:12 AM, deadalnix wrote:
>>> To be honest I'm to a point were I'm starting withdrawing from these
>>> conversation because I have no idea how to reach to you guys.
>>
>> You committed to author a proposal a few months back. Did you make
>> progress on that? -- Andrei
>
> Are you referring to this one?
>
> https://github.com/dlang/DIPs/pull/16

That was related to safety and lifetimes. I've created the study group specifically to encourage positive contribution from talented folks instead of negative reaction. Sadly it hasn't bore fruit yet. It is surprising deadalnix still frames the discussion as him proposing things and not being heard; my perception is he consistently refuses to contribute literally anything in spite of my desperate attempts to get him to work on something - anything -, and instead chooses to wait on the sidelines and criticize destructively any attempt to make progress. -- Andrei

On 8/12/16 8:28 AM, Seb wrote:
> On Friday, 12 August 2016 at 12:29:21 UTC, Andrei Alexandrescu wrote:
>> On 8/12/16 6:12 AM, deadalnix wrote:
>>> To be honest I'm to a point were I'm starting withdrawing from these
>>> conversation because I have no idea how to reach to you guys.
>>
>> You committed to author a proposal a few months back. Did you make
>> progress on that? -- Andrei
>
> Are you referring to this one?
>
> https://github.com/dlang/DIPs/pull/16

One of our clocks is skewed, which is it? -- Andrei

On Friday, 12 August 2016 at 12:41:07 UTC, Andrei Alexandrescu wrote:
> On 8/12/16 8:28 AM, Seb wrote:
>> On Friday, 12 August 2016 at 12:29:21 UTC, Andrei Alexandrescu wrote:
>>> On 8/12/16 6:12 AM, deadalnix wrote:
>>>> To be honest I'm to a point were I'm starting withdrawing from these
>>>> conversation because I have no idea how to reach to you guys.
>>>
>>> You committed to author a proposal a few months back. Did you make
>>> progress on that? -- Andrei
>>
>> Are you referring to this one?
>>
>> https://github.com/dlang/DIPs/pull/16
>
> One of our clocks is skewed, which is it? -- Andrei

Wait - you are not "from the future"? :O

http://i.imgur.com/9pvCtXR.png

(I just checked my phone and it seems to be in sync)

On Thursday, 11 August 2016 at 08:53:22 UTC, John Colvin wrote:
> On Thursday, 11 August 2016 at 08:45:38 UTC, Walter Bright wrote:
>> On 8/11/2016 1:29 AM, John Colvin wrote:
>>> Can someone talk me through the lifetime algebra for the following?
>>>
>>> void foo()
>>> {
>>>     int a;
>>>     int** c;
>>>     void bar()
>>>     {
>>>         int* b = &a;  <= ok, b has a smaller lifetime than a
>>>         c = &b;    <= error, c has a larger lifetime than b
>>>     }
>>>     bar();
>>>     *c; //undefined behaviour
>>> }
>
> but according to this rule:
>
> "For an unrestricted pointer, visibility is dictated by the usual lexical scope rules. Lifetime, however is dictated by the lifetime of the data to which the pointer points to."
>
> b should have the same lifetime as a, no?

ping on this? I want to understand what's going on here and be another set of eyes checking for mistakes, but I'm stuck on this bit of the spec.

On Thursday, 11 August 2016 at 21:57:06 UTC, Walter Bright wrote:
>> auto arr = RefCountedSlice!int(10);
>> auto ptr = &arr[5];
>> arr = RefCountedSlice!int(42);
>> *ptr = 1;    // use after free
>
> The idea is to have containers return references by 'return ref' or 'return scope' so the internal references can't escape the expression they're used in.

What expressions are allowed? Will this work?

auto arr = RefCountedSlice!int(10);
void f(scope ref int n)
{
  arr = RefCountedSlice!int(42);
  n = 1; // use after free
}
f(arr[5]);

On Fri, 12 Aug 2016 10:24:22 +0000, Robert burner Schadek wrote:

>> No, the DIP doesn't handle several levels of indirection.
> 
> What about:
> 
> struct Bar { int a; int b }
> auto rcs = RefCountedTree!(string,Bar)();
> 
> fcs["bar"].a = 1337;  // log n
> fcs["bar"].b = 1338;  // log n
> 
> ? I need to pay log n twice to assign two members

In the worst case, you can change the API so you can write:

rcs.update("bar", (x) { x.a = 1337; x.b = 1338; });

On Friday, 12 August 2016 at 14:02:50 UTC, Chris Wright wrote:
> In the worst case, you can change the API so you can write:
>
> rcs.update("bar", (x) { x.a = 1337; x.b = 1338; });

yes, but that will not catch on. And I think (x) must be (scope ref x)

On Fri, Aug 12, 2016 at 01:27:08PM +0000, Kagamin via Digitalmars-d wrote:
> On Thursday, 11 August 2016 at 21:57:06 UTC, Walter Bright wrote:
> > > auto arr = RefCountedSlice!int(10);
> > > auto ptr = &arr[5];
> > > arr = RefCountedSlice!int(42);
> > > *ptr = 1;    // use after free
> > 
> > The idea is to have containers return references by 'return ref' or 'return scope' so the internal references can't escape the expression they're used in.
> 
> What expressions are allowed? Will this work?
> 
> auto arr = RefCountedSlice!int(10);
> void f(scope ref int n)
> {
>   arr = RefCountedSlice!int(42);
>   n = 1; // use after free
> }
> f(arr[5]);

Nice one!

But I believe the current rules ought to catch this case as well, because if RefCountedSlice!int(42) returns by scope, then assigning it to arr would be illegal (lifetime of arr is longer than lifetime of the new slice).


T

-- 
"No, John.  I want formats that are actually useful, rather than over-featured megaliths that address all questions by piling on ridiculous internal links in forms which are hideously over-complex." -- Simon St. Laurent on xml-dev