www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Favorite bug?

reply Brad Roberts <braddr puremagic.com> writes:
I'll probably regret starting this thread in a day or to, but out of 
curiosity's sake, if you had to pick a single bug to be fixed in the next 
1.x bug fix release, what would it be and why?  Remember, just one per 
person.

NOTE: This is just a poll, not any sort of guarantee that it'll be fixed 
or even looked at.  I'm doing this purely out of my own personal 
curiosity.

Later,
Brad
Jul 01 2007
next sibling parent Derek Parnell <derek nomail.afraid.org> writes:
On Sun, 1 Jul 2007 23:42:37 -0700 (PDT), Brad Roberts wrote:

 I'll probably regret starting this thread in a day or to, but out of 
 curiosity's sake, if you had to pick a single bug to be fixed in the next 
 1.x bug fix release, what would it be and why?  Remember, just one per 
 person.
 
 NOTE: This is just a poll, not any sort of guarantee that it'll be fixed 
 or even looked at.  I'm doing this purely out of my own personal 
 curiosity.

Allowing inappropriate implicit conversions of signed values to unsigned variables. For example allowing a 'uint' to be initialized to a negative number. Why? Because it hides bugs that the compiler could catch. C:\temp>type test.d import std.stdio; void foo(uint b) { writefln(`foo says "%s"`, b); } void main() { uint x = -1; // Should be a compile-time error writefln("%d", x); int y = -2; x = y; // Should be a runtime error at least. writefln("%d", x); foo(-3); // Should have a "no matching method" error foo(y); // Should have a "no matching method" error } C:\temp>dmd test y:\dmd\bin\..\..\dm\bin\link.exe test,,,user32+kernel32/noi; C:\temp>test 4294967295 4294967294 foo says "4294967293" foo says "4294967294" -- Derek (skype: derek.j.parnell) Melbourne, Australia 2/07/2007 5:52:05 PM
Jul 02 2007
prev sibling next sibling parent Brad Roberts <braddr puremagic.com> writes:
Derek Parnell wrote:
 On Sun, 1 Jul 2007 23:42:37 -0700 (PDT), Brad Roberts wrote:
 
 I'll probably regret starting this thread in a day or to, but out of 
 curiosity's sake, if you had to pick a single bug to be fixed in the next 
 1.x bug fix release, what would it be and why?  Remember, just one per 
 person.

 NOTE: This is just a poll, not any sort of guarantee that it'll be fixed 
 or even looked at.  I'm doing this purely out of my own personal 
 curiosity.

Allowing inappropriate implicit conversions of signed values to unsigned variables. For example allowing a 'uint' to be initialized to a negative number. Why? Because it hides bugs that the compiler could catch.

Let me clarify my intent: What's your favorite bugzilla reported issue. What you pointed out is a hotly debatable point that's not in the set I'm interested in. :) Later, Brad
Jul 02 2007
prev sibling next sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
1083 (classtype.classinfo.name can't be evaluated in compile-time)... while I'm
not sure if I directly have a use for it now (since my current DSource project
is actually in Java...), I can definitely see why this would be useful for
metaprogramming.

Closely followed by (I know you said one per person but...):

1258 (Garbage collector loses memory upon array concatenation) - The fix looks
easy, though Walter must have commented that line out for a reason... ANyways,
if you can't trust the garbage collector [insert witty statement here].

929 (Resizing array of associative arrays (uint[char[]][]) causes infinite loop
/ hang) - Actually _been_ bitten by this one

987 (Add DMD compiler switch to prevent automatic linking to
phobos.lib/libphobos.a) - because the whole tango/phobos split is tearing my
mind apart

As you can probably guess, I only went through the P1s and
"blowout"/"critical"s, so I'm sure there are probably more suitable ones
somewhere down there.

How about you, Brad?
Jul 02 2007
prev sibling next sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Brad Roberts" <braddr puremagic.com> wrote in message 
news:mailman.54.1183358567.16939.digitalmars-d puremagic.com...
 I'll probably regret starting this thread in a day or to, but out of
 curiosity's sake, if you had to pick a single bug to be fixed in the next
 1.x bug fix release, what would it be and why?  Remember, just one per
 person.

 NOTE: This is just a poll, not any sort of guarantee that it'll be fixed
 or even looked at.  I'm doing this purely out of my own personal
 curiosity.

 Later,
 Brad

102/282/912 -- Yes, I know, three reported bugs, but they're all because of the same issue: FORWARD REFERENCING. This really, _really_ needs to be fixed. And come on, 102 is ancient, there's no excuse for this bug to have been known for so long and not have been fixed. And that it's been reported at least three times means that yes, people do run into this.
Jul 02 2007
prev sibling next sibling parent Deewiant <deewiant.doesnotlike.spam gmail.com> writes:
Brad Roberts wrote:
 I'll probably regret starting this thread in a day or to, but out of 
 curiosity's sake, if you had to pick a single bug to be fixed in the next 
 1.x bug fix release, what would it be and why?  Remember, just one per 
 person.
 
 NOTE: This is just a poll, not any sort of guarantee that it'll be fixed 
 or even looked at.  I'm doing this purely out of my own personal 
 curiosity.
 

313 and 314: I can't choose which of the two I would like first. They make enforcing correct usage of modules difficult. Okay, so it's not that bad when it's your own code, but they make the protection identifiers pretty much useless. After that, 340, for obvious reasons. Of the sub-issues, 810 is foremost.
Jul 02 2007
prev sibling next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Brad Roberts wrote:
 I'll probably regret starting this thread in a day or to, but out of 
 curiosity's sake, if you had to pick a single bug to be fixed in the next 
 1.x bug fix release, what would it be and why?  Remember, just one per 
 person.
 
 NOTE: This is just a poll, not any sort of guarantee that it'll be fixed 
 or even looked at.  I'm doing this purely out of my own personal 
 curiosity.
 
 Later,
 Brad

#52 for me. Referring to a function by name only gets you the first version that appears lexically. No warning about conflicting overloads. Unfortunately I also dread seeing this one fixed, because I suspect the fix is going to be just to make it an error, and/or require casting to the exact version you want with a monstrosity like: cast(return_type function(int,double,char[]) &fn --bb
Jul 02 2007
parent reply "Craig Black" <cblack ara.com> writes:
"Bill Baxter" <dnewsgroup billbaxter.com> wrote in message 
news:f6asup$2sjh$1 digitalmars.com...
 Brad Roberts wrote:
 I'll probably regret starting this thread in a day or to, but out of 
 curiosity's sake, if you had to pick a single bug to be fixed in the next 
 1.x bug fix release, what would it be and why?  Remember, just one per 
 person.

 NOTE: This is just a poll, not any sort of guarantee that it'll be fixed 
 or even looked at.  I'm doing this purely out of my own personal 
 curiosity.

 Later,
 Brad

#52 for me. Referring to a function by name only gets you the first version that appears lexically. No warning about conflicting overloads. Unfortunately I also dread seeing this one fixed, because I suspect the fix is going to be just to make it an error, and/or require casting to the exact version you want with a monstrosity like: cast(return_type function(int,double,char[]) &fn --bb

It would be ideal if it was interpreted as a special type of function pointer that knows about all the overloads, and then identifies the exact overload when it is assigned. That would be cool. -Craig
Jul 02 2007
parent BCS <ao pathlink.com> writes:
Reply to Craig,

 "Bill Baxter" <dnewsgroup billbaxter.com> wrote in message
 news:f6asup$2sjh$1 digitalmars.com...
 
 Brad Roberts wrote:
 #52 for me.
 Referring to a function by name only gets you the first version that
 appears lexically.  No warning about conflicting overloads.
 Unfortunately I also dread seeing this one fixed, because I suspect
 the fix is going to be just to make it an error, and/or require
 casting to the exact version you want with a monstrosity like:
 
 cast(return_type function(int,double,char[]) &fn
 

pointer that knows about all the overloads, and then identifies the exact overload when it is assigned. That would be cool.

how about &fn give you a tuple?
Jul 02 2007
prev sibling next sibling parent reply BCS <ao pathlink.com> writes:
Reply to Brad,

 I'll probably regret starting this thread in a day or to, but out of
 curiosity's sake, if you had to pick a single bug to be fixed in the
 next 1.x bug fix release, what would it be and why?  Remember, just
 one per person.
 
 NOTE: This is just a poll, not any sort of guarantee that it'll be
 fixed or even looked at.  I'm doing this purely out of my own personal
 curiosity.
 
 Later,
 Brad

switch(n) { alias T!(1,2,3,4,5) Tp; foreach(int i, int j; Tp) { case j: // fails: non const case Tp[i]: // passes break; } }
Jul 02 2007
parent reply Walter Bright <newshound1 digitalmars.com> writes:
BCS wrote:
 switch(n)
 {
 alias T!(1,2,3,4,5) Tp;
 foreach(int i, int j; Tp)
 {
   case j: // fails: non const
   case Tp[i]: // passes
    break;
 }
 }

That one was fixed.
Jul 02 2007
parent reply BCS <ao pathlink.com> writes:
Reply to Walter,

 BCS wrote:
 
 switch(n)
 {
 alias T!(1,2,3,4,5) Tp;
 foreach(int i, int j; Tp)
 {
 case j: // fails: non const
 case Tp[i]: // passes
 break;
 }
 }


when? Am I just out of date?
Jul 02 2007
parent reply Walter Bright <newshound1 digitalmars.com> writes:
BCS wrote:
 That one was fixed.


You're 1 day out of date <g>.
Jul 02 2007
parent reply BCS <ao pathlink.com> writes:
Reply to Walter,

 BCS wrote:
 
 That one was fixed.
 



Was that an unlisted bug fix or am I not recognizing the bug in the list?
Jul 02 2007
parent reply BCS <ao pathlink.com> writes:
Reply to Benjamin,

 Reply to Walter,
 
 BCS wrote:
 
 That one was fixed.
 



list?

never mind 1118 also covers that one
Jul 02 2007
parent reply Witold Baryluk <baryluk smp.if.uj.edu.pl> writes:
BCS wrote:

 never mind 1118 also covers that one

And 1245 ?
Jul 11 2007
parent reply BCS <ao pathlink.com> writes:
Reply to Witold,

 BCS wrote:
 
 never mind 1118 also covers that one
 


actually I have code that it still doesn't work for (v1.018)
 And 1245 ?
 

that is a different issue
Jul 11 2007
parent BCS <ao pathlink.com> writes:
Reply to Benjamin,

 Reply to Witold,
 
 BCS wrote:
 
 never mind 1118 also covers that one
 


 And 1245 ?
 


AND the issue I was talking about (oops)
Jul 11 2007
prev sibling next sibling parent Jason House <jason.james.house gmail.com> writes:
In general, I'm concerned with portability right now.

The top of my hit list is issue #72 (or related GC issues).  Using 
dynamic memory kills gdc 0.23 in any sufficiently complex program.

The next on my hit list is the non-portability of timing function calls.

Both those issues have a pile of posts from me trying to resolve them on 
the D.learn group.

Brad Roberts wrote:
 I'll probably regret starting this thread in a day or to, but out of 
 curiosity's sake, if you had to pick a single bug to be fixed in the next 
 1.x bug fix release, what would it be and why?  Remember, just one per 
 person.
 
 NOTE: This is just a poll, not any sort of guarantee that it'll be fixed 
 or even looked at.  I'm doing this purely out of my own personal 
 curiosity.
 
 Later,
 Brad

Jul 02 2007
prev sibling next sibling parent Witold Baryluk <baryluk smp.if.uj.edu.pl> writes:
Brad Roberts wrote:

 I'll probably regret starting this thread in a day or to, but out of
 curiosity's sake, if you had to pick a single bug to be fixed in the next
 1.x bug fix release, what would it be and why?  Remember, just one per
 person.
 
 NOTE: This is just a poll, not any sort of guarantee that it'll be fixed
 or even looked at.  I'm doing this purely out of my own personal
 curiosity.
 
 Later,
 Brad

102, "forward referencing beetwen files." 312, "bypassing imports" 318, "wait does not release thread resources on Linux", important!
Jul 11 2007
prev sibling parent Manfred Nowak <svv1999 hotmail.com> writes:
Brad Roberts wrote

 what would it be and why?

Fixing the two years old undetected ambiguity bug: import std.stdio; class Foo { this( int x, int y){ writefln( "two parm");}; this( int x ){ writefln( "one parm");}; } void test( Foo f ...){} void test( int x, Foo f ...){} void main(){ test( 1, 1); // ambiguities: // test( Foo(1,1)) // test( 1, Foo(1)) } because this sort of ambiguities seems intractable. -manfred
Jul 11 2007