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
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 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
Jan 16
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
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
Jan 16
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
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
Jan 17
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Wednesday, January 17, 2018 09:32:30 Simen Kjrs 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
Jan 17
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
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.
Jan 17
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
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
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
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
Jan 17
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
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
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
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