Zach the Mystic:

> You can see exactly how D works by looking at how Kenji spends his time. For a while he's only been fixing ICEs and other little bugs which he knows for certain will be accepted.

I agree that probably there are often better ways to use Kenji time for the development of D.

Bye,
bearophile

Andrei Alexandrescu:

> I'm following with interest the discussion "My Reference Safety System (DIP???)". Right now it looks like a lot of work - a long opener, subsequent refinements, good discussion. It also seems just that - there's work but there's no edge to it yet; right now a DIP along those ideas is more likely to be rejected than approved. But I certainly hope something good will come out of it.

The second scope proposal looks simpler than the first:
http://wiki.dlang.org/User:Schuetzm/scope2

Later in Rust they have added some lifetime inference to reduce the annotation burden in many cases.

Bye,
bearophile

On Friday, 27 February 2015 at 21:19:31 UTC, Andrei Alexandrescu wrote:
> On 2/27/15 1:07 PM, H. S. Teoh via Digitalmars-d wrote:
>> What about this, if we're serious about @safe actually*guaranteeing*
>> anything: after 2.067 is released, we reimplement @safe by making it
>> reject every language construct by default.
>
> I don't think this is practical. It's a huge amount of work over a long time.

That's easy enough to solve, though. The new behaviour can at first be opt-in, enabled by a command-line flag (like we already do with -dip25). We have an entire release cycle, or longer if we need that, to get at least Phobos and druntime to compile. Once that is done, people can test their own code with it, and it can be enabled on the auto-tester by default.

When some time has passed, we invert the switch - it's then opt-out. People can still disable it if they just want to get their code to compile without fixing it (or reporting a bug if it's our fault). Finally, the old behaviour can be removed altogether.

>
> Besides, even with that approach there's still no guarantee; implementation bugs are always possible in either approach.
>

As H.S. Teoh said, these can be detected by git bisect.

> I think the closest thing to what you're after is progress and preservation proofs on top of a core subset of the language. It would be great if somebody wanted to do this.

Wouldn't that effectively mean introducing another kind of `@safe`, that only allows to use said core subset? Or a compiler switch? How else would it be practicable?

On Saturday, 28 February 2015 at 10:40:32 UTC, bearophile wrote:
> Andrei Alexandrescu:
>
>> I'm following with interest the discussion "My Reference Safety System (DIP???)". Right now it looks like a lot of work - a long opener, subsequent refinements, good discussion. It also seems just that - there's work but there's no edge to it yet; right now a DIP along those ideas is more likely to be rejected than approved. But I certainly hope something good will come out of it.
>
> The second scope proposal looks simpler than the first:
> http://wiki.dlang.org/User:Schuetzm/scope2
>

Still working on it, but I think we're on the right track. Zach had some really good ideas.

> Later in Rust they have added some lifetime inference to reduce the annotation burden in many cases.

I just modified Walter's RCArray to work with the new proposal. It looks almost identical, but now supports safe slicing. (It currently lacks a way to actually get an RCArray of a slice, but that can be added as an `alias this`). There's only one `scope` annotation in the entire code. Even though the proposal includes a `return` annotation, it's not needed in this case.

In general, if it works out like I imagine, there will be almost no annotations. They will only ever be necessary for function signatures, and then only in `@system` code, `extern`/`export` declarations, and occasionally for `@safe` functions. Everything else will just work. (@safe will become slightly stricter, but that's a good thing.)

On 2/28/15 7:53 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm@gmx.net>" wrote:
> On Friday, 27 February 2015 at 21:19:31 UTC, Andrei Alexandrescu wrote:
>> On 2/27/15 1:07 PM, H. S. Teoh via Digitalmars-d wrote:
>>> What about this, if we're serious about @safe actually*guaranteeing*
>>> anything: after 2.067 is released, we reimplement @safe by making it
>>> reject every language construct by default.
>>
>> I don't think this is practical. It's a huge amount of work over a
>> long time.
>
> That's easy enough to solve, though.

I figure there are ways to go about it. I just don't find it practical. It might have been a good idea eight years ago. -- Andrei

On 2/27/2015 7:33 AM, H. S. Teoh via Digitalmars-d wrote:
> @safe has some pretty nasty holes right now... like:
>
> 	https://issues.dlang.org/show_bug.cgi?id=5270
> 	https://issues.dlang.org/show_bug.cgi?id=8838
> 	https://issues.dlang.org/show_bug.cgi?id=12822
> 	https://issues.dlang.org/show_bug.cgi?id=13442
> 	https://issues.dlang.org/show_bug.cgi?id=13534
> 	https://issues.dlang.org/show_bug.cgi?id=13536
> 	https://issues.dlang.org/show_bug.cgi?id=13537
> 	https://issues.dlang.org/show_bug.cgi?id=14136
> 	https://issues.dlang.org/show_bug.cgi?id=14138

None of those are a big deal (i.e. fundamental), and are certainly not a justification for throwing the whole thing out and starting over. Some of them aren't even in the core language, but in incorrect usage of @trusted in Phobos.

Just fix them.

On Friday, 27 February 2015 at 02:58:31 UTC, Andrei Alexandrescu wrote:
> On 2/26/15 6:17 PM, H. S. Teoh via Digitalmars-d wrote:
>> On Thu, Feb 26, 2015 at 05:57:53PM -0800, Andrei Alexandrescu via Digitalmars-d wrote:
>>> On 2/26/15 5:48 PM, Zach the Mystic wrote:
>>>> I sometimes feel so bad for Kenji, who has come up with several
>>>> reasonable solutions for longstanding problems, *and* implemented
>>>> them, only to have them be frozen for *years* by indecision at the
>>>> top.
>>>
>>> Yah, we need to be quicker with making decisions, even negative. This
>>> requires collaboration from both sides - people shouldn't get furious
>>> if their proposal is rejected. Kenji has been incredibly gracious
>>> about this.
>> [...]
>>
>> I don't think people would be furious if they knew from the beginning
>> that something would be rejected. At least, most reasonable people
>> won't, and I'm assuming that the set of unreasonable people who
>> contribute major features is rather small (i.e., near cardinality 0).
>
> Well yes in theory there's no difference between theory and practice etc. What has happened historically (fortunately not as much lately) was that statistically most proposals have been simply Not Good. Statistically, proposal authors have been Positively Convinced that their proposals were of Obviously Excellent. (That includes me; statistically most ideas I've ever had have been utter crap, but seldom seemed like it in the beginning.) This cycle has happened numerous times. We've handled that poorly in the past, and we're working on handling it better.
>
>> What *does* make people furious / disillusioned is when they are led to
>> believe that their work would be accepted, and then after they put in
>> all the effort to implement it, make it mergeable, keep it up to date
>> with the moving target of git HEAD, etc., it then gets summarily
>> dismissed.  Or ignored for months and years, and then suddenly shot
>> down. Or worse, get *merged*, only to be reverted later because the
>> people who didn't bother giving feedback earlier now show up and decide
>> that they don't like the idea after all.  (It's a different story if
>> post-merge rejection happened because it failed in practice -- I think
>> reasonable people would accept that.  But post-merge rejection because
>> of earlier indecision / silence kills morale really quickly. Don't
>> expect to attract major contributors if morale is low.)
>
> Yes, getting back on a decision or promise is a failure of leadership. For example, what happened with [$] was regrettable. We will do our best to avoid such in the future.
>
> I should add, however, that effort in and by itself does not warrant approval per se. Labor is a prerequisite of any good accomplishment, but is not all that's needed.
>
> I'm following with interest the discussion "My Reference Safety System (DIP???)". Right now it looks like a lot of work - a long opener, subsequent refinements, good discussion. It also seems just that - there's work but there's no edge to it yet; right now a DIP along those ideas is more likely to be rejected than approved. But I certainly hope something good will come out of it. What I hope will NOT happen is that people come to me with a mediocre proposal going, "We've put a lot of Work into this. Well?"
>
>
> Andrei

I'm curious if project management(e.g., MS Project) is used to optimize and clarify goals for the D language?

If such a project was maintained, anyone could download it and see the current state of D.

The main use being the optimization of tasks and display the "timeline". If something has been sitting around for a year and is blocking other tasks then you can easily see that.

It obviously would lot of work to setup such a project. I imagine you could write some script to import data from github or whatever into the project and possibly vice versa.

On 2/28/15 12:20 PM, Sativa wrote:
> I'm curious if project management(e.g., MS Project) is used to optimize
> and clarify goals for the D language?

I've pushed for trello for a good while, it didn't catch up. -- Andrei

On Saturday, 28 February 2015 at 21:11:54 UTC, Andrei Alexandrescu wrote:
> On 2/28/15 12:20 PM, Sativa wrote:
>> I'm curious if project management(e.g., MS Project) is used to optimize
>> and clarify goals for the D language?
>
> I've pushed for trello for a good while, it didn't catch up. -- Andrei

Trello would be nice, it even has a good feature request/voting system IIRC.

On 2/27/2015 2:42 AM, Dominikus Dittes Scherkl wrote:
> How can we make progress,

Look at the changelog, there's tremendous progress.