Temtaime:

> It requires a little more attention and that's all.
> Please, stop creating such "fake" enchantments and go to fix real bugs. Thanks.

I don't agree they are fake :-) We have removed several classes of common C bugs from D with those enhancements, and there is still some space left for improvements :-)

Bye,
bearophile

On Monday, 24 March 2014 at 03:55:41 UTC, bearophile wrote:
> Seasoned C/C++/D programmers watch for the types every time they perform a division, to avoid that trap. But less experienced programmers introduce bugs with divisions. Can D help the programmer reduce the frequency of similar bugs? And do we want to?

We are passed the initial stage of designing the language. D is used now in lots of real code. The focus now has to be on completing the original design, and maybe making small non-breaking improvements where practical. Discussions about fundamental changes to the language like this, while interesting, are distracting and counterproductive.

On Mon, Mar 24, 2014 at 07:19:58PM +0000, Peter Alexander wrote:
> On Monday, 24 March 2014 at 03:55:41 UTC, bearophile wrote:
> >Seasoned C/C++/D programmers watch for the types every time they perform a division, to avoid that trap. But less experienced programmers introduce bugs with divisions. Can D help the programmer reduce the frequency of similar bugs? And do we want to?
> 
> We are passed the initial stage of designing the language. D is used now in lots of real code. The focus now has to be on completing the original design, and maybe making small non-breaking improvements where practical.  Discussions about fundamental changes to the language like this, while interesting, are distracting and counterproductive.

Don't we have a wiki page for ideas for "future D" (or D3?)? These ideas
can go on that page.


T

-- 
English is useful because it is a mess. Since English is a mess, it maps well onto the problem space, which is also a mess, which we call reality. Similarly, Perl was designed to be a mess, though in the nicests of all possible ways. -- Larry Wall

Peter Alexander:

> We are passed the initial stage of designing the language. D is used now in lots of real code.

I'd like D improve some more.


> The focus now has to be on completing the original design,

The original D design is to make a language that is "focused on safety", so we are still working to complete it :-)


> and maybe making small non-breaking improvements where practical.

I think the problem raised in this thread could have a very limited negative impact on correct existing D code, and a positive impact in finding wrong code.


> Discussions about fundamental changes to the language like this,

It's not a fundamental change, I think it's a sufficiently limited change. As usual you can be sure only when you apply such ideas on real D code.


> are distracting and counterproductive.

It's not distracting, because it focuses on something you do often (divisions), and it's hopefully productive because it could avoid some bugs and decrease the time spent performing rote manual code review.

Bye,
bearophile

H. S. Teoh:

> Don't we have a wiki page for ideas for "future D" (or D3?)? These ideas can go on that page.

I don't think Andrei will want a D3 language, so better to keep the focus on D2 first :-) And he is right because there are still some parts of D2 unfinished. The little type system improvement suggested in this thread is meant for D2.

Bye,
bearophile

On 3/24/14, 12:51 PM, bearophile wrote:
> Peter Alexander:
>
>> We are passed the initial stage of designing the language. D is used
>> now in lots of real code.
>
> I'd like D improve some more.

The single most impactful way to improve D some more at this point is, without a shred of doubt, reviewing pull requests on github. Anyone who has any nontrivial interest in the future of D should help us turn the ratchet by reviewing pull requests. Anything - potential bugs found, safety suggestions, efficiency suggestions, LGTM - would help the core team drain that pipe.

>> are distracting and counterproductive.
>
> It's not distracting, because it focuses on something you do often
> (divisions), and it's hopefully productive because it could avoid some
> bugs and decrease the time spent performing rote manual code review.

If you diverted 1.0/10 (sic!) of the effort you put in these discussions in reviewing pull requests, that would help us all put up a lot better with the distraction.


Andrei

On Monday, 24 March 2014 at 20:02:51 UTC, Andrei Alexandrescu wrote:
> The single most impactful way to improve D some more at this point is, without a shred of doubt, reviewing pull requests on github.

I've been through most Phobos pulls several times now in the last few months, and from what I can tell a lot of pulls seem to be stalled by the pull authors themselves rather than a lack of reviewers. Someone makes a pull, it gets reviewed but turns out the pull needs more work, and then the author disappears from the face of the earth.

Andrei Alexandrescu:

> The single most impactful way to improve D some more at this point is, without a shred of doubt, reviewing pull requests on github.

My time is more efficiently used suggesting people new ideas to create new pull requests :-)


> If you diverted 1.0/10 (sic!) of the effort you put in these discussions in reviewing pull requests, that would help us all put up a lot better with the distraction.

Instead of ignoring my arguments of this thread, if you want please comment regarding the merits of the idea of catching some of the division-related problems.

Bye,
bearophile

On Mon, 24 Mar 2014 16:11:34 -0400, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:

> On Monday, 24 March 2014 at 20:02:51 UTC, Andrei Alexandrescu wrote:
>> The single most impactful way to improve D some more at this point is, without a shred of doubt, reviewing pull requests on github.
>
> I've been through most Phobos pulls several times now in the last few months, and from what I can tell a lot of pulls seem to be stalled by the pull authors themselves rather than a lack of reviewers. Someone makes a pull, it gets reviewed but turns out the pull needs more work, and then the author disappears from the face of the earth.

2 things:

1. Pulls that are waiting for author changes, but haven't been touched in a week (maybe?) should be closed. They can always be reopened.
2. Pulls that are closed do not get tested, so they are not using up cycles on the auto tester.

-Steve

On 3/24/14, 1:11 PM, Andrej Mitrovic wrote:
> On Monday, 24 March 2014 at 20:02:51 UTC, Andrei Alexandrescu wrote:
>> The single most impactful way to improve D some more at this point is,
>> without a shred of doubt, reviewing pull requests on github.
>
> I've been through most Phobos pulls several times now in the last few
> months, and from what I can tell a lot of pulls seem to be stalled by
> the pull authors themselves rather than a lack of reviewers. Someone
> makes a pull, it gets reviewed but turns out the pull needs more work,
> and then the author disappears from the face of the earth.

Those should be closed. -- Andrei