www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - I closed a very old bug!

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jan 16 2018
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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

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
Jan 16 2018
prev sibling next sibling parent reply Mark <smarksc gmail.com> writes:
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



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
Jan 16 2018
next sibling parent reply Simen =?UTF-8?B?S2rDpnLDpXM=?= <simen.kjaras gmail.com> writes:
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



 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
Jan 17 2018
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
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



 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
Jan 17 2018
next sibling parent 12345swordy <alexanderheistermann gmail.com> writes:
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



 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.
Jan 17 2018
prev sibling parent reply Simen =?UTF-8?B?S2rDpnLDpXM=?= <simen.kjaras gmail.com> writes:
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
Jan 18 2018
parent Simen =?UTF-8?B?S2rDpnLDpXM=?= <simen.kjaras gmail.com> writes:
On Thursday, 18 January 2018 at 09:15:04 UTC, Simen Kjærås wrote:

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


So, a few more thoughts on this:

Arrays and pointers automatically decay to their Unqual'ed 
variants when passed to a templated function. AAs do not, which 
makes sense given their reference-type nature. Structs and 
classes don't, and in general shouldn't. Simple types, like ints 
and floats, don't.

As a matter of fact, Unqual is too blunt an instrument for what 
we want to do - Unqual!(const(MyStruct)) == MyStruct, regardless 
of what's inside MyStruct. For a struct with aliasing (one that 
contains pointers or arrays), that behavior is plain wrong for 
our use case.

What is actually needed here is a template that gives the 
equivalent head-mutable type, such that it can be put in a 
variable. For const(int), that's int. For const(int[]), int[]. 
For a const(MyStruct), it's const(MyStruct) or MyStruct, 
depending on whether MyStruct has aliasing. This test already 
exists in the compiler (try to assign a const struct {int[] arr; 
int i;} to a mutable variable, then try the same without the 
array).

This takes care of the non-templated problems, but the big issue 
is still ahead of us. For templates, as stated earlier, the 
connection between T and its head-mutable variant can be 
arbitrarily complex. However, a single function template is all 
that's needed to convey all the necessary information. Let's call 
it opDecay, and give this implementation of the basic logic:

template Decay(T)
{
     import std.traits : Unqual, hasAliasing, isAssociativeArray;
     static if (is(typeof(T.init.opDecay())))
     {
         alias Decay = typeof(T.init.opDecay());
     }
     else static if (is(T == class) || isAssociativeArray!T ||
                    (is(T == struct) && hasAliasing!(Unqual!T)))
     {
         alias Decay = T;
     }
     else
     {
         alias Decay = Unqual!T;
     }
}

unittest
{
     // Regular types:
     assert(is(Decay!(const int) == int));
     assert(is(Decay!(const int*) == const(int)*));
     assert(is(Decay!(const int[]) == const(int)[]));
     assert(is(Decay!(const int[10]) == int[10]));
     assert(is(Decay!(const int[int]) == const(int[int])));

     // Struct without aliasing:
     static struct S1 {
         int n;
         immutable(int)[] arr;
     }
     assert(is(Decay!(const S1) == S1));

     // Struct with aliasing:
     static struct S2 {
         int[] arr;
     }
     assert(is(Decay!(const S2) == const S2));

     // Struct with aliasing, with opDecay hook:
     static struct S3 {
         int[] arr;
         S3 opDecay(this T)() {
             return S3(arr.dup);
         }
     }
     assert(is(Decay!(const S3) == S3));

     // Templated struct with aliasing, with opDecay hook
     struct S4(T) {
         T[] arr;
         auto opDecay(this This)() const {
             import std.traits : CopyTypeQualifiers;
             return S4!(CopyTypeQualifiers!(This, T))(arr.dup);
         }
     }
     assert(is(Decay!(const S4!int) == S4!(const int)));
}

We now have a way of obtaining head-mutable variables of any type 
that supports it. Alias this takes care of implicit conversion to 
the decayed type ...except when it doesn't. As stated above, 
arrays decay when passed to a templated function:

import std.range;

void foo(T)(T arr) {
     assert(is(T == const(int)[]));
     assert(isInputRange!T);
}
unittest {
     const(int[]) a;
     foo(a);
     assert(!isInputRange!(typeof(a)));
}

This behavior is special - no types other than T* and T[] decay 
in this way, and there's no way to tell the compiler you want 
your type to do the same. Is it important that our types do the 
same? I'm not entirely sure. The fact that this decay is 
inconsistent[1] today makes me even less sure. If we want the 
same kind of behavior for user-defined types, the compiler will 
need to insert calls to opDecay when a type with that method is 
passed to a function[2].

opDecay is likely to be a small function that can be inlined and 
in many cases elided altogether, and will only be used for a 
small subset of types, so I believe the overhead of calling it 
whenever a type with the method is passed to another function, 
would be negligible.

Destroy!

--
   Simen

[1]: https://issues.dlang.org/show_bug.cgi?id=18268
[2]: If typeof(x.opDecay) != typeof(x), and the type of the 
parameter is not explicitly typeof(x).
Jan 19 2018
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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


 

 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
Jan 17 2018
next sibling parent reply rjframe <dlang ryanjframe.com> writes:
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...
Jan 18 2018
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/18/18 7:17 AM, rjframe wrote:

 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.


I put a "DIP needed" mention in text and closed the issue with REMIND. I 
suggest similar treatment for similar issues. -- Andrei
Jan 18 2018
prev sibling parent Jon Degenhardt <jond noreply.com> writes:
On Thursday, 18 January 2018 at 07:46:03 UTC, 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. Seb is 
 experimenting with moving the entire bug database to github 
 issues, which may offer us more options for classification.


It would make sense to separate bugs from enhancements in this 
regard. It's useful to record and maintain useful enhancements 
ideas even if they don't fit the current priorities. There are 
multiple ways to implement this, but it'd be most useful if the 
distinction between "bugs" and "enhancements" is obvious and easy 
to discover.

--Jon
Jan 18 2018
prev sibling parent Seb <seb wilzba.ch> writes:
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
Jan 17 2018