On 7/10/14, 2:27 PM, H. S. Teoh via Digitalmars-d wrote:
> On Thu, Jul 10, 2014 at 02:21:54PM -0700, Andrei Alexandrescu via Digitalmars-d wrote:
> [...]
>> http://wiki.dlang.org/MVPs
> [...]
>
> Should this be merged with http://wiki.dlang.org/People ?

Yah, let's go with People. Thanks! -- Andrei

On Friday, 11 July 2014 at 01:08:59 UTC, Andrei Alexandrescu wrote:
> On 7/10/14, 2:25 PM, Walter Bright wrote:
>> On 7/10/2014 1:49 PM, Robert Schadek via Digitalmars-d wrote:
>>> https://github.com/D-Programming-Language/phobos/pull/1977 indexOfNeither
>>
>> I want to defer this to Andrei.
>
> Merged. -- Andrei

For any other aspiring lieutenants out there, this[0] has been sitting around for 5 months now.

[0]https://github.com/D-Programming-Language/phobos/pull/1965#issuecomment-40362545

On Friday, 11 July 2014 at 01:09:38 UTC, Andrei Alexandrescu wrote:
> On 7/10/14, 2:27 PM, H. S. Teoh via Digitalmars-d wrote:
>> On Thu, Jul 10, 2014 at 02:21:54PM -0700, Andrei Alexandrescu via Digitalmars-d wrote:
>> [...]
>>> http://wiki.dlang.org/MVPs
>> [...]
>>
>> Should this be merged with http://wiki.dlang.org/People ?
>
> Yah, let's go with People. Thanks! -- Andrei

Done. http://wiki.dlang.org/?title=MVPs&redirect=no

On Fri, Jul 11, 2014 at 01:01:20AM +0000, Meta via Digitalmars-d wrote:
> On Thursday, 10 July 2014 at 17:04:24 UTC, H. S. Teoh via Digitalmars-d wrote:
> 
> Can you copy and paste the text from your original post? It's difficult to read on the web interface.

I'm working on a DIP for this, actually. Hopefully it will be more fleshed out than what I posted. I'll post the link when it's ready.


T

-- 
The problem with the world is that everybody else is stupid.

On Thursday, 10 July 2014 at 13:51:42 UTC, Andrei Alexandrescu wrote:
> Yes, the arguments come and go by in forum discussions. To avoid this we need a well-written DIP that has a section illustrating the insufficiencies of library solutions, and then proposes the few needed additions to the language that make the thing work properly. Other language communities have done this with good results.
>
> Andrei

I've made several DIPs. Some of them solving existing problems being discussed right now (what happen with delegates when you have this + context for instance, is solved).

Most of them never gathered any attention.

I'm willing to write this one as well, but my time isn't infinite, and ultimately, every time I do something like this, it is time I don't spend on SDC. Considering the attention these get, I simply cannot put this in high position in my priority queue.

I'm bugging around with a similar proposal for a while, but quite fail to put the last pieces in place. It goes similar in

On Thursday, 10 July 2014 at 17:04:24 UTC, H. S. Teoh via Digitalmars-d wrote:
>    - For function parameters, this lifetime is the scope of the function
>      body.

Some kind of inout scope seem less limiting. The caller know the scope, the callee know that is is greater than itself. It is important as local variable in the outer scope of the function have more restricted scope and must not be assignable.

Each parameter have a DIFFERENT lifetime, but it is impossible to tell which one is larger from the callee perspective. Thus you must have a more complex lifetime definition than grater/smaller lifetime. Yup, when you get into the details, quantum effects start to arise.

>>    - An unscoped variable is regarded to have infinite lifetime.
>> 

So it is not unscoped, but I'm simply nitpicking on that one.

>>       - Since a scoped return type has its lifetime as part of its type,
>>         the type system ensures that scoped values never escape their
>>         lifetime. For example, if we are sneaky and return a pointer to
>>         an inner function, the type system will prevent leakage of the

This get quite tricky to define when you can have both this and a context pointer. Once again, you get into a situation where you have 2 non sortable lifetime to handle. And worse, you'll be creating values out of that mess :)

>> - Aggregates:
>> 
>>    - It's turtles all the way down: members of scoped aggregates also
>>      have scoped type, with lifetime inherited from the parent
>>      aggregate. In other words, the lifetime of the aggregate is
>>      transitive to the lifetime of its members.

Yes rule for access is transitivity. But the rule to write is "antitransitive". It gets tricky when you consider that a member variable may have to be able to "extend" the lifetime of one of its member.

IE a member of lifetime B in a value of lifetime A sees it lifetime becoming max(A, B). Considering lifetime aren't always sortable (as show in 2 examples), this is tricky.

This basically means that you have to define what happen for non sortable lifetime, and what happen for union/intersection of lifetime. As you see, I've banged my head quite a lot on that one. I'm fairly confident that this is solvable, but definitively require a lot of effort to iron out all the details.

>> - Passing parameters: since unscoped values are regarded to have
>>   infinite lifetime, it's OK to pass unscoped values into scoped
>>   function parameters: it's a narrowing of lifetime of the original
>>   value, which is allowed. (What's not allowed is expanding the lifetime
>>   of a scoped value.)
>> 

Get rid of the whole concept of unscopped, and you get rid of a whole class of redundant definition that needs to be done.

>> I'm sure there are plenty of holes in this proposal, so destroy away.
>> ;-)
>> 

Need some more iron. But I'm happy to see that some people came up with proposal that are close to what I had in mind.

The above mentioned detail may seems scary, but I'm confident these will only cause problems in a small variety of cases.

An aspect of the proposal that isn't mentioned is postblit and destructions. scoping will need to redefine theses.

Ultimately I love the idea and think D should go in that direction at some point. But now I'd prefers see things ironed out in general in D (@safe is a good example).

On Thursday, 10 July 2014 at 20:10:38 UTC, Marc Schütz wrote:
> Instead of lifetime intersections with `&` (I believe Timon proposed that in the original thread), simply specify multiple "owners": `scope!(a, b)`. This works, because as far as I can see there is no need for lifetime unions, only intersections.
>

There are unions.

class A {
   scope!s1(A) a;
}

scope!s2(A) b;

b.a; // <= this has union lifetime of s1 and s2.

On 10/07/2014 19:03, Walter Bright wrote:
> On 7/10/2014 9:00 AM, Nick Treleaven wrote:
>> On 09/07/2014 20:55, Walter Bright wrote:
>>>    Unique!(int*) u = new int;   // must work
>>
>> That works, it's spelled:
>>
>> Unique!int u = new int;
>
> I'm unconfortable with that design, as T can't be a class ref or a
> dynamic array.

It does currently work with class references, but not dynamic arrays:

    Unique!Object u = new Object;

It could be adjusted so that all non-value types are treated likewise:

    Unique!(int[]) v = [1, 3, 2];

>>>    int* p = new int;
>>>    Unique!(int*) u = p;         // must fail
>>
>> The existing design actually allows that, but nulls p:
>  > [...]
>> If there are aliases of p before u is constructed, then u is not the
>> sole owner
>> of the reference (mentioned in the docs):
>> http://dlang.org/phobos-prerelease/std_typecons.html#.Unique
>
> Exactly. It is not checkable and not good enough.

In that case we'd need to deprecate Unique.this(ref RefT p) then.

> Note that as of 2.066 the compiler tests for uniqueness of an expression
> by seeing if it can be implicitly cast to immutable. It may be possible
> to do that with Unique without needing compiler modifications.

Current Unique has a non-ref constructor that only takes rvalues. Isn't that good enough to detect unique expressions?

>> Also related is whether we use alias this to expose the resource
>> (allowing
>> mutation but not replacement) or if we use opDispatch. Currently, it
>> uses opDot,
>> which AFAICT is basically opDispatch. If we use alias this, that's
>> a(nother)
>> hole exposing non-unique access to the resource.
>
> The holes must be identified and closed.

OK, opDispatch then.

> BTW, I'm amenable to adjusting the compiler to recognize Unique and help
> out as a last resort.

On Thursday, 10 July 2014 at 22:50:51 UTC, Walter Bright wrote:
> On 7/10/2014 1:52 PM, bearophile wrote:
>> Walter Bright:
>>
>>> I can't imagine users going to the bother of typing all that, let alone what
>>> happens when they do it wrong. Most users don't really have a good handle on
>>> what the lifetimes of their data are, so how are they going to annotate it
>>> correctly?
>>
>> I suggest you to go in the Rust mailing list and ask this question again.
>
> Rust has very little experience in real projects. I know that people see all the hype about Rust and believe it has proved itself, but it hasn't.
>
> I've read other papers about annotations in Java and how people just refused to annotate their references.

This might have something to do with both the mindset of Java ("isn't the runtime supposed to take care of this sort of thing?") and the fact that Java is already monstrously verbose.

On 10/07/14 22:31, Walter Bright wrote:

> I don't know the PR link nor do I know what pseudonym you use on github,
> so please help!
>
> I reiterate my complaint that people use "virtual functions" for their
> github handles. There's no reason to. Who knows that 9il is actually
> Ilya Yaroshenko? Took me 3 virtual function dispatches to find that out!

Talking about Github pseudonyms. I think it's very confusing that Hara Kenji is using a different author for his commits than his Github pseudonym. He commits as "k-hara", which doesn't exist on Github. But his Github pseudonym is "9rnsr".

-- 
/Jacob Carlborg