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

I think it would be great to reduce the median age of open issues, and the median longevity of closed issues. I'm in talks with Sebastian about publishing such metrics. One obvious way to improve that is to look at old bugs - I suspect many are simple or have been fixed already.


Andrei

On Tue, Jan 16, 2018 at 02:45:06PM -0500, Andrei Alexandrescu via Digitalmars-d wrote:
> https://issues.dlang.org/show_bug.cgi?id=255
> 
> I think it would be great to reduce the median age of open issues, and the median longevity of closed issues. I'm in talks with Sebastian about publishing such metrics. One obvious way to improve that is to look at old bugs - I suspect many are simple or have been fixed already.
[...]

It's not hard to setup prebaked bugzilla queries that return very old bugs, sorted by various criteria.  Currently, I've setup for myself a bunch of prebaked queries named "1-2yo bugs", "2-10yo bugs", "last 6 months", etc..  Finding old bugs are just 1 click away.

Many old bugs are non-trivial to fix, though (the easy ones have already been fixed, obviously). Like #340, which has a very long list of dependencies, most of which have been closed but the remainder of which are not so simple to fix.


T

-- 
War doesn't prove who's right, just who's left. -- BSD Games' Fortune

On Tuesday, 16 January 2018 at 19:45:06 UTC, Andrei Alexandrescu wrote:
> https://issues.dlang.org/show_bug.cgi?id=255
>
> I think it would be great to reduce the median age of open issues, and the median longevity of closed issues. I'm in talks with Sebastian about publishing such metrics. One obvious way to improve that is to look at old bugs - I suspect many are simple or have been fixed already.
>
>
> Andrei

What about #5337 [1] ? It's the oldest Phobos bug in Bugzilla, from 2010. It seems to be a proposal for tail-const support for Phobos ranges, accompanied by an implementation. Should something be done about that? I never felt the need for tail-const in the language.

[1] https://issues.dlang.org/show_bug.cgi?id=5377

On Tuesday, 16 January 2018 at 22:01:43 UTC, Mark wrote:
> On Tuesday, 16 January 2018 at 19:45:06 UTC, Andrei Alexandrescu wrote:
>> https://issues.dlang.org/show_bug.cgi?id=255
>>
>> I think it would be great to reduce the median age of open issues, and the median longevity of closed issues. I'm in talks with Sebastian about publishing such metrics. One obvious way to improve that is to look at old bugs - I suspect many are simple or have been fixed already.
>>
>>
>> Andrei
>
> What about #5337 [1] ? It's the oldest Phobos bug in Bugzilla, from 2010. It seems to be a proposal for tail-const support for Phobos ranges, accompanied by an implementation. Should something be done about that? I never felt the need for tail-const in the language.
>
> [1] https://issues.dlang.org/show_bug.cgi?id=5377

As the person who filed that bug, I say close it. It was filed in response to clamor in the newsgroup about how D was unusable without tail const - an assertion that has proven baseless.

--
  Simen

On Tuesday, 16 January 2018 at 19:45:06 UTC, Andrei Alexandrescu wrote:
> ...
> I'm in talks  with Sebastian about publishing such metrics.

For those who don't know about the graphs from auto-tester. They are the best metric we have at the moment:

https://auto-tester.puremagic.com/chart.ghtml?projectid=1

On Wednesday, January 17, 2018 09:32:30 Simen Kjærås via Digitalmars-d wrote:
> On Tuesday, 16 January 2018 at 22:01:43 UTC, Mark wrote:
> > On Tuesday, 16 January 2018 at 19:45:06 UTC, Andrei
> >
> > Alexandrescu wrote:
> >> https://issues.dlang.org/show_bug.cgi?id=255
> >>
> >> I think it would be great to reduce the median age of open issues, and the median longevity of closed issues. I'm in talks with Sebastian about publishing such metrics. One obvious way to improve that is to look at old bugs - I suspect many are simple or have been fixed already.
> >>
> >>
> >> Andrei
> >
> > What about #5337 [1] ? It's the oldest Phobos bug in Bugzilla, from 2010. It seems to be a proposal for tail-const support for Phobos ranges, accompanied by an implementation. Should something be done about that? I never felt the need for tail-const in the language.
> >
> > [1] https://issues.dlang.org/show_bug.cgi?id=5377
>
> As the person who filed that bug, I say close it. It was filed in response to clamor in the newsgroup about how D was unusable without tail const - an assertion that has proven baseless.

D is quite useable without tail-const, but without it, ranges and const can't be used together. The solution that most of us have taken is basically to give up on const. Having tail-const would be better, but implementing it without language support is a royal pain and not the sort of thing that most of us are going to bother with. It's just easier to give up on const. It would be a _lot_ nicer if we could figure out how to cleanly add tail-const to the language.

- Jonathan M Davis

On Wednesday, 17 January 2018 at 10:36:44 UTC, Jonathan M Davis wrote:
> On Wednesday, January 17, 2018 09:32:30 Simen Kjærås via Digitalmars-d wrote:
>> On Tuesday, 16 January 2018 at 22:01:43 UTC, Mark wrote:
>> > On Tuesday, 16 January 2018 at 19:45:06 UTC, Andrei
>> >
>> > Alexandrescu wrote:
>> >> https://issues.dlang.org/show_bug.cgi?id=255
>> >>
>> >> I think it would be great to reduce the median age of open issues, and the median longevity of closed issues. I'm in talks with Sebastian about publishing such metrics. One obvious way to improve that is to look at old bugs - I suspect many are simple or have been fixed already.
>> >>
>> >>
>> >> Andrei
>> >
>> > What about #5337 [1] ? It's the oldest Phobos bug in Bugzilla, from 2010. It seems to be a proposal for tail-const support for Phobos ranges, accompanied by an implementation. Should something be done about that? I never felt the need for tail-const in the language.
>> >
>> > [1] https://issues.dlang.org/show_bug.cgi?id=5377
>>
>> As the person who filed that bug, I say close it. It was filed in response to clamor in the newsgroup about how D was unusable without tail const - an assertion that has proven baseless.
>
> D is quite useable without tail-const, but without it, ranges and const can't be used together. The solution that most of us have taken is basically to give up on const. Having tail-const would be better, but implementing it without language support is a royal pain and not the sort of thing that most of us are going to bother with. It's just easier to give up on const. It would be a _lot_ nicer if we could figure out how to cleanly add tail-const to the language.
>
> - Jonathan M Davis

Which you need to write a DIP in order to do it.

On 1/16/18 5:01 PM, Mark wrote:
> On Tuesday, 16 January 2018 at 19:45:06 UTC, Andrei Alexandrescu wrote:
>> https://issues.dlang.org/show_bug.cgi?id=255
>>
>> I think it would be great to reduce the median age of open issues, and the median longevity of closed issues. I'm in talks with Sebastian about publishing such metrics. One obvious way to improve that is to look at old bugs - I suspect many are simple or have been fixed already.
>>
>>
>> Andrei
> 
> What about #5337 [1] ? It's the oldest Phobos bug in Bugzilla, from 2010. It seems to be a proposal for tail-const support for Phobos ranges, accompanied by an implementation. Should something be done about that? I never felt the need for tail-const in the language.
> 
> [1] https://issues.dlang.org/show_bug.cgi?id=5377

There's been some discussion about what to do with issues that propose enhancements like this. We want to make them available and searchable just in case someone working on a related proposal is looking for precedent and inspiration.

I was thinking of closing with REMIND or LATER. Seb is experimenting with moving the entire bug database to github issues, which may offer us more options for classification.


Andrei

On Wednesday, 17 January 2018 at 10:36:44 UTC, Jonathan M Davis wrote:
> D is quite useable without tail-const, but without it, ranges and const can't be used together. The solution that most of us have taken is basically to give up on const. Having tail-const would be better, but implementing it without language support is a royal pain and not the sort of thing that most of us are going to bother with. It's just easier to give up on const. It would be a _lot_ nicer if we could figure out how to cleanly add tail-const to the language.

Sadly, constness doesn't propagate in a straightforward way - the equivalent const type for Foo!(int, int) could be Foo!(int, const(int)), Foo!(const(int), int), or Foo!(const(int), const(int)), and there's no way to specify this. At least in theory, it might even be that the const version is an entirely different template instantiation, so even something like `struct Foo(T, inout U)` might not be good enough. We might decide not to support anything as weird as different template overload sets, though.

If we look at what we already have, the basic building block is std.traits.Unqual. What's needed is a hook for those cases where Unqual!(const(R!T)) shouldn't simply be R!T. If Unqual tested for a member, e.g. "Unqual", and returned that type, that's important parts of the issue solved.

"Unqual" would probably be on the form 'alias Unqual(this T) = Foo!(CopyTypeQualifiers!(T, Args));'.

The big thing missing after amending Unqual like this, is implicit conversion. Currently, const(Foo!T) is generally not implicitly convertible to Foo!(const(T)). Since D templates are complex beasts, again there's not necessarily a straightforward way to do this. Alias this is some help, but trying to get that to work I ran into https://issues.dlang.org/show_bug.cgi?id=18260.

At any rate, this is a topic for a DIP.

--
  Simen

On Thu, 18 Jan 2018 02:46:03 -0500, Andrei Alexandrescu wrote:

> There's been some discussion about what to do with issues that propose enhancements like this. We want to make them available and searchable just in case someone working on a related proposal is looking for precedent and inspiration.
> 
> I was thinking of closing with REMIND or LATER.

If you're specifically talking about enhancements that would require a DIP, calling it "DIP needed" (or similar) is clear that work is needed to get it in, rather than just some "we'll look at this at some point" kind of label.

>  Seb is experimenting
> with moving the entire bug database to github issues, which may offer us
> more options for classification.

You'd get fewer classification options, though they may be easier to work with effectively; sometimes simpler is better...