On 1/2/2015 4:05 PM, Joseph Rushton Wakeling via Digitalmars-d wrote:
> On 02/01/15 23:50, Walter Bright via Digitalmars-d wrote:
> That said, I don't see any pressing need for something formal at this point in
> time.  Some friendly suggestions, guidelines or advice -- that's another thing
> and doesn't need to be provided in a formal way.

If it's posted with a link, it's then formal.

I handle things on a case by case basis (and there isn't much of it, thankfully). It works well enough. We've got a community here we can be proud of.

On 3 January 2015 at 10:07, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 1/2/2015 2:38 PM, Joseph Rushton Wakeling via Digitalmars-d wrote:
>>
>> On 02/01/15 22:16, Walter Bright via Digitalmars-d wrote:
>>>
>>> I don't believe it is impossible to implement in D, in fact, Bartosz
>>> Milewski
>>> proposed such a system some years back. I do believe that people will
>>> simply
>>> reject such a system as too hard to use.
>>
>>
>> Isn't that dependent on the use-case, though?  We know very well that
>> games
>> programmers (for example) will jump through programming fire, compared to
>> many
>> other developers, in order to achieve their desired results.
>
>
> Take a look at noted game developer Jonathan Blow's videos. They'll jump through hoops for performance, but I see little evidence they will do so for correctness. It's like have a nun stand over you and rap your knuckles every time your handwriting isn't perfect. Nobody likes that.

I feel like your resistance of comprehensive scope is some part
emotional, some part anecdotal... but little or not parts
experimentally based.
You appear to 'fear' what it would do... and maybe you have the
experience to judge that better than me, but I just can't see it!


>> Assuming that we're not going to lose the default case of the GC being
>> responsible for allocation/ownership unless the programmer specifies
>> otherwise,
>> what's wrong with having a rigorous ownership system in place that can be
>> made
>> use of if and only if the programmer sees value in it?
>
>
> Because of the viral nature of it, you cannot avoid it. It's like trying to avoid using const.

scope isn't like const though, it's a different thing. I think you're
just trying to incite FUD with that particular comparison.
It doesn't inhibit interoperation of data the same way as const does.
It only inhibits interoperation in the case of escaping local data to
the outside world.
Cases where we currently allow that (because the tech we have is
insufficient to detect the cases) are probably bugs. They violate D's
safety guarantees, and that's a core commitment of D.
I don't think we can ever really make good on the @safe commitment
without scope/lifetime. So from that perspective, we either need to
take scope seriously, or stop advertising that we take safety
seriously.

In practise, I suspect it would be more like pure or nothrow in its
impact. How many hours do you spend wrangling pure or nothrow issues
compared to const issues?
I can say that pure/nothrow barely ever cause me any trouble, and when
they do, I'm often surprised that they actually reveal what would have
been a bug.

An awful lot of the modern big-ticket problems in software engineering are relating to ownership.


>> I hope it's obvious what I'm getting at here -- a really simple, general
>> and
>> powerful syntax can become horrendously complicated to deal with once you
>> start
>> going beyond a certain scale of combinations.
>
>
> Don't I know it :-)

We're already there though. And to resist one more with very
significant importance is drawing an arbitrary line. You got behind
@nogc fairly recently with no particular friction...
We already know we have to get better at attribute inference, that's
critical to addressing the situation we are already in. Assuming we
succeed with that (we must, and it's not a particularly hard problem
anyway), then that solution applies equally for this case too.

But if we have drawn a hard line in terms of quantity of attributes, I would gladly sacrifice @nogc, or nothrow in favour of scope.

On 1/2/15 1:17 PM, Joseph Rushton Wakeling via Digitalmars-d wrote:
> On 02/01/15 10:26, Andrei Alexandrescu via Digitalmars-d wrote:
>> Good stuff, thanks. Question about this:
>
> I'm glad it seems useful; I wondered after writing if it was a bit too
> much of a rambling mess :-P
>
>>> TL;DR: I think it would be good to have a strong community guideline
>>> that people are not to be criticized or treated badly for having
>>> requests or suggestions, even if they are not willing to implement
>>> them themselves.  The quid pro quo is that it's necessary to be
>>> (calmly) candid with people about the limits of _only_ contributing
>>> ideas or requests: "You can ask but not demand".
>>
>> What would be an appropriate place to put this?
>
> How about a link at the top of the forum.dlang.org page saying something
> like, "Before posting, please read our _community guidelines_" ?  With
> the page linked to containing advice like the above.
>
> I know that there's always been a lot of pride that we've always been
> able to get along without some kind of code of conduct, but ... well,
> guidelines are not the same as a code, and anyway, not having guidance
> just doesn't scale in my experience.

https://issues.dlang.org/show_bug.cgi?id=13928

Andrei

On 1/2/15 4:05 PM, Joseph Rushton Wakeling via Digitalmars-d wrote:
> That said, I don't see any pressing need for something formal at this
> point in time.  Some friendly suggestions, guidelines or advice --
> that's another thing and doesn't need to be provided in a formal way.

So now should I close https://issues.dlang.org/show_bug.cgi?id=13928 that I just created? :o) -- Andrei

On 3/01/2015 7:55 p.m., Andrei Alexandrescu wrote:
> On 1/2/15 4:05 PM, Joseph Rushton Wakeling via Digitalmars-d wrote:
>> That said, I don't see any pressing need for something formal at this
>> point in time.  Some friendly suggestions, guidelines or advice --
>> that's another thing and doesn't need to be provided in a formal way.
>
> So now should I close https://issues.dlang.org/show_bug.cgi?id=13928
> that I just created? :o) -- Andrei

Please don't. While I understand Walters position to not formalizing a set of do's and dont's, we do still need something even if its just a mantra shown if a cookie is not present in the NG web interface.
It can be as simple as, this is a professional communication facility for furthering the D programming language. Please respect the goals of the community.

On 1/2/2015 11:31 PM, Rikki Cattermole wrote:
> On 3/01/2015 7:55 p.m., Andrei Alexandrescu wrote:
>> On 1/2/15 4:05 PM, Joseph Rushton Wakeling via Digitalmars-d wrote:
>>> That said, I don't see any pressing need for something formal at this
>>> point in time.  Some friendly suggestions, guidelines or advice --
>>> that's another thing and doesn't need to be provided in a formal way.
>>
>> So now should I close https://issues.dlang.org/show_bug.cgi?id=13928
>> that I just created? :o) -- Andrei

Yes.


> Please don't. While I understand Walters position to not formalizing a set of
> do's and dont's, we do still need something even if its just a mantra shown if a
> cookie is not present in the NG web interface.
> It can be as simple as, this is a professional communication facility for
> furthering the D programming language. Please respect the goals of the community.

No evidence we need that, and if we did, that it would be effective. Explained in a previous post.

On 1/2/2015 9:27 PM, Manu via Digitalmars-d wrote:
> I feel like your resistance of comprehensive scope is some part
> emotional, some part anecdotal... but little or not parts
> experimentally based.
> You appear to 'fear' what it would do... and maybe you have the
> experience to judge that better than me, but I just can't see it!

Hardly anyone understood DIP69, and that one is very simple compared to a comprehensive ownership system.


>> Because of the viral nature of it, you cannot avoid it. It's like trying to
>> avoid using const.
> scope isn't like const though, it's a different thing. I think you're
> just trying to incite FUD with that particular comparison.
> It doesn't inhibit interoperation of data the same way as const does.
> It only inhibits interoperation in the case of escaping local data to
> the outside world.

That's a lot of handwaving.


> Cases where we currently allow that (because the tech we have is
> insufficient to detect the cases) are probably bugs. They violate D's
> safety guarantees, and that's a core commitment of D.
> I don't think we can ever really make good on the @safe commitment
> without scope/lifetime. So from that perspective, we either need to
> take scope seriously, or stop advertising that we take safety
> seriously.

DIP25 and 69 make it safe.


> We're already there though. And to resist one more with very
> significant importance is drawing an arbitrary line.

Propose a design. I suggest, though, that if it was half as easy as you say, it would already exist in multiple languages. It's not like nobody thought of it before.


"Maybe some track lighting will help!"

  -- https://www.youtube.com/watch?feature=player_detailpage&v=P9FHlhWqbus#t=17

On 1 Jan 2015 18:46, "Joseph Rushton Wakeling via Digitalmars-d" < digitalmars-d@puremagic.com> wrote:
>
> On 29/12/14 05:13, Andrei Alexandrescu via Digitalmars-d wrote:
>>
>> I did want to say something about this. I've given a close read to the
"Lost a
>> new commercial user this week" thread, through and through. It seems I've identified a problem that belongs to us. ("Us" is a vacuous term meaning
"the
>> leaders of the D community").
>>
>> My initial read of your complaint went like this: it's about Windows (I
don't
>> even have an installation), it's about vibe.d (haven't used it yet), and
it's
>> also discussing documentation (which is something we can indeed improve
and I
>> know how to). So a large part of the problem wasn't even mine to work on.
>>
>> Others harbored similar perceptions. The corollary has been that
essentially
>> you're asking them to stop working on D aspects they do care about and
start
>> working on D aspects you and others care about - all on their free time.
>
>
> A few thoughts on this.  (This turned a bit longer than expected in the
writing, so I've highlighted some TL;DR sections to highlight key ideas.)
>
> I think that one of the most common sources of community friction in open
source is people mistaking being _asked_ to work on something that someone else cares about, for being _expected_ to do so.
>
> That's very unfortunate, because it means that all too often people will
come into a community, full of enthusiasm for this new thing they've discovered, make some suggestions, and get shot down like they're some sort of plague carrier. (The D community is pretty good at not doing this with newcomers, but deals less well with people repeatedly raising ideas; more on that in a moment.)
>
> Obviously, there are people who display an enormous sense of entitlement,
who are rude or just throw demands around in a very arrogant way.  But simply saying, "I want this", "I need this", or "I think this would be a good idea" should not IMO be a trigger for criticism or hostility.  Most of the time, people do understand the fundamental constraints of a volunteer community with limited resources, and what they are interested in having is either acknowledgement of a good idea or use-case (preferably with something getting onto a TODO list, but not necessarily with any priority), or feedback that helps them understand alternative ways to solve their problem.  (Caveat: it matters whether the problem is actually solved, or just worked around.)
>

I've stopped here (I'm reading from a phone and travelling), but some thoughts come to mind when it comes to persistent offenders/questions.

1. DIPs should be process of getting a new feature / breaking change through - not the ML.

People who want changes strong enough should be encouraged to raise one.

2. Why does D not do X? And other frequent questions should go in a FAQ with a clear answer.  This hopefully isn't the rule but I sense sometimes the reason certain things come up again and again are because either of the following:

a. Responses vary or change over time.  So the original reason and motivation for rejection gets lost.

b. There is no official rejection stamp for ideas that spring up from the ML compared to DIPs.

Having this in a FAQ serves the purposes of both (a) and (b).

3. Bounties were supposed to address some aspects of feature driven goals.

I don't think this works in practice but the thought process seemed sound, in terms of:

a.  Someone has an idea and raises it in the ML.
b. A DIP is created, along with a bugzilla report and bounty.
c. More bounties that go in drives popularity and the likelihood of a PR
being raised to implement the DIP.

I don't have an alternate proposal to this, but I recognize that upvotes in bugzilla don't drive incentives either.

Though you may have raised some good points on these. :)

Iain.

On Saturday, 3 January 2015 at 00:06:10 UTC, Joseph Rushton Wakeling via Digitalmars-d wrote:
> Obviously D does not have such a problem right now, but as the number of people active on the forums grows, there are inevitably going to be more and more instances of people behaving antisocially, and that does in turn make it more important to have some mechanism to ensure they are dealt with fairly and not arbitrarily.

I've heard this a few times before over the years, and it hasn't happened yet. Perhaps we're not growing at the the necessary rapid rate, but I think new people try to blend into what they see other people doing, so as long as at any given time, the majority of us behave fairly well, it will stay that way.

I agree with what you're saying about a fair process and I don't think some guidelines about how to deal with trouble would be bad, even if it is as simple as "please don't feed the trolls" or even "turn the other cheek"*. But I also think we're doing OK as it is right now and have been for a lot of years and probably will be for many years more.


* fun fact, a lot of people see the "eye for an eye" thing as being like a gross cruel and unusual punishment, but at the time, it was actually quite progressive - it put limits on executive power! If the rule is tooth for a tooth, the disciplinarian can't arbitrarily decide to draw and quarter you because you punched his buddy in the face. Goes to what you said about the fair process.

On Saturday, 3 January 2015 at 08:41:44 UTC, Walter Bright wrote:
> On 1/2/2015 9:27 PM, Manu via Digitalmars-d wrote:
>> I feel like your resistance of comprehensive scope is some part
>> emotional, some part anecdotal... but little or not parts
>> experimentally based.
>> You appear to 'fear' what it would do... and maybe you have the
>> experience to judge that better than me, but I just can't see it!
>
> Hardly anyone understood DIP69, and that one is very simple compared to a comprehensive ownership system.

Does this mean that D is not going to get a comprehensive ownership system in a later edition (like D3)?

Because if that is not on the roadmap then I think you need to spend a lot more effort on getting an efficient precise GC if you want D to survive.

> Propose a design. I suggest, though, that if it was half as easy as you say, it would already exist in multiple languages. It's not like nobody thought of it before.

How about making all functions that take references/pointers templates and define protocols for relaying information to the compiler? I know Manu will hate that, but are you against it?