On 7/10/2014 8:29 AM, Sean Kelly wrote:
> And I
> know I'm not alone. Robert's struggle with getting std.logger accepted is the
> stuff told to children around the campfire so they don't venture out into the dark.

If it makes you feel better, it happens to me too. Everyone assumes someone else is responsible for pulling, and the end result is nothing happens. For example, this one:

https://github.com/D-Programming-Language/dmd/pull/3613

On 7/10/14, 10:56 AM, Walter Bright wrote:
> On 7/10/2014 6:55 AM, Andrei Alexandrescu wrote:
>> On 7/10/14, 12:21 AM, Walter Bright wrote:
>>> On 7/10/2014 12:03 AM, deadalnix wrote:
>>>> So runtime error or php style better anything than nothing for
>>>> something that
>>>> can be checked statically...
>>>
>>> I don't understand your comment.
>>
>> It's very simple. The semantics you propose is move with the syntax of
>> copy.
>> Following the implicit move, the source of it is surprisingly modified
>> (emptied).
>
> Right, that is what I proposed.
>
>> That doesn't work. There is a humongous body of knowledge accumulated
>> in C++
>> with std::auto_ptr. That artifact has been quite the show, including
>> people who
>> swore by it (!). We'd do good to simply draw from that experience
>> instead of
>> reenacting it.
>
> I accept that you're right, but I don't know why. I perused the link you
> provided earlier, and wasn't too enlightened.
>
> It was clear from those links that unique_ptr<T> is working successfully
> - what is different about that?

We discussed this with Bartosz literally for weeks (him being a fan of auto_ptr for too long, later completely converted against it and I take credit for that :o)). With auto_ptr this was possible:

auto_ptr<int> a(new int);
auto_ptr<int> b = a;

It would nullify a with copy syntax. That code won't compile with unique_ptr; you'd need an explicit move(a).

It only got worse from there: passing into functions, member variables...

MOVING WITH COPY SYNTAX DOES NOT WORK.

It's cut and dried.


Andrei

On 7/10/14, 11:01 AM, safety0ff wrote:
> It's difficult to believe that everybody is too busy to review PRs yet
> have ample time to invest in the most futile of forum discussions.

Amen to that.

Andrei

On 7/10/2014 8:51 AM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> but it would help a lot if you just specced out
> the D2 language fully and plotted in the missing parts, without implementation,
> but with proofs of correctness. All this putting stuff in, then ripping it out
> is demotivating. (Why contribute if it will be ripped out at the next turn of
> events?)

Again, you're asking Andrei and I to do all the work.

On 7/10/14, 11:39 AM, Walter Bright wrote:
> On 7/10/2014 8:29 AM, Sean Kelly wrote:
>> And I
>> know I'm not alone. Robert's struggle with getting std.logger accepted
>> is the
>> stuff told to children around the campfire so they don't venture out
>> into the dark.
>
> If it makes you feel better, it happens to me too. Everyone assumes
> someone else is responsible for pulling, and the end result is nothing
> happens. For example, this one:
>
> https://github.com/D-Programming-Language/dmd/pull/3613

Well I just pulled that. -- Andrei

On Thu, Jul 10, 2014 at 06:32:06PM +0000, Sean Kelly via Digitalmars-d wrote:
> On Thursday, 10 July 2014 at 18:25:56 UTC, H. S. Teoh via Digitalmars-d wrote:
> >On Thu, Jul 10, 2014 at 06:01:09PM +0000, safety0ff via
> >>
> >>This is exactly the typical contributor experience.
> >
> >Which we must change if we're going to increase D adoption. Unfortunately, I don't see any good solution to this, except just hoping for more contributors to pick up different pieces of Phobos as their "passion" and become the "lieutenant" for that part of it. But that requires first of all that contributors are motivated to contribute, yet the current situation isn't encouraging them to join in. It's a vicious cycle, and I don't know how to break it.
> 
> I think part of this will have to come from a policy change regarding pull requests.  I propose that any pull request must either be merged or rejected within one month of submission.  I'd rather see a request rejected with an explanation than for it to languish in revision hell for months or years while people slowly iterate on changes.  It's better in my minds to submit a request, have it rejected with comments, fix and resubmit multiple times than to have pull requests just sitting in the queue forever with no one knowing what their status is.

That's a good start; I like that.

Another thing that might help, is if we can somehow change the default sort order on the github PR page. Currently it's defaulted to newest first, but that's a horrible default order given our circumstances. A much better order is "least recently updated", so that the oldest, most ignored PRs will get attention first. Even if they are mostly ignored, at least every time somebody goes to that page they'll see it in passing, and perhaps decide one day to actually look into what it is. As opposed to the current situation of "out of sight, out of mind".


T

-- 
Любишь кататься - люби и саночки возить.

On 7/10/2014 9:53 AM, H. S. Teoh via Digitalmars-d wrote:
> Since we're on this topic, I wish somebody would review this PR:
>
> 	https://github.com/D-Programming-Language/phobos/pull/2276

I'll have a go.

BTW, I had no idea quickfur was you. I know people like using pseudonyms on github, but the D community is large and it takes me a long time to connect in my brain which ng member is which github contributor.

I.e. I wish y'all would use github accounts under your own name. It's not like there's anything on there that'll embarrass anyone if it goes on the front page of the nytimes :-) and nobody should be tempted to post such stuff.

On 07/10/2014 08:59 AM, Walter Bright wrote:
> On 7/9/2014 8:12 PM, Timon Gehr wrote:
>>> 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?
>>> ...
>> ...
>
>> Fundamentally, we need syntax for (examples provided for illustration,
>> those are
>> not proposals):
>>
>> - Parametric polymorphism
>>
>> Eg.: void foo[A](int x){ ... }
>
> What does that do?
> ...

It's a mechanism for compile-time parameters with homogeneous translation. (It is sufficient if it supports lifetimes at this point, but inout could profit as well.)

We get a (potentially) differently typed function 'foo' for every argument `A', but it is the same function at runtime, hence this works for virtual methods and function pointers/delegates.

>
>> - Lifetime parameters. (it's more future-proof if they are not
>> introduced by
>> simple identifiers.)
>>
>> Eg.: void foo[lifetime lt](int x){ ... }
>
> ??
> ...

This introduces a compile-time parameter that is a lifetime. (It's not a use case, just an example.)

>
>> - 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.)
>
> This seems awfully complicated.
>...

Are you talking about the concept, the examples, or just the last example? What makes it seem complicated?

On Thu, Jul 10, 2014 at 11:50:57AM -0700, Walter Bright via Digitalmars-d wrote:
> On 7/10/2014 9:53 AM, H. S. Teoh via Digitalmars-d wrote:
> >Since we're on this topic, I wish somebody would review this PR:
> >
> >	https://github.com/D-Programming-Language/phobos/pull/2276
> 
> I'll have a go.

Thanks!


> BTW, I had no idea quickfur was you. I know people like using pseudonyms on github, but the D community is large and it takes me a long time to connect in my brain which ng member is which github contributor.
> 
> I.e. I wish y'all would use github accounts under your own name. It's not like there's anything on there that'll embarrass anyone if it goes on the front page of the nytimes :-) and nobody should be tempted to post such stuff.

I didn't exactly go out of my way to *hide* my real name, y'know -- it's right on my github profile in a prominent font if you'd only click on my pseudonym.  ;-) Surely it's not *that* hard?


T


-- 
What are you when you run out of Monet? Baroque.

On Thursday, 10 July 2014 at 18:46:08 UTC, Walter Bright wrote:
> Again, you're asking Andrei and I to do all the work.

Well, I could spec a draft, but it would be met with too much resistance based on what people have gotten used to (habits, for good or bad). Only you and Andrei can put force behind changes that will pry dangerous toys out of the hands of the habitants…

So I think the more fruitful approach for me is find a minimal representation that can cover C, most of D2 and close follow ups, let's call them D++ or D--. That way you don't break most code and can do whole program analysis/optimization with proper @safe validation…

Seems to me that you can have many languages in the same build and do semantic analysis on the whole. Provided that the generated languages (after generics have been instantiated) are close in semantics, of course.

That's the best I can come up with… Not what you are asking for, but what you are asking for will never make me happy ;-)