www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Bug reports [Was: Re: About Andrei's interview, part 3]

reply bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:
I just hope you can be realistic about how much can be done about them in the
short term.<

Most of of my bugzilla entries are normal bugs, suggestions for improved error messages and diagnostic, Phobos bugs, enhancement requests, _additive_ changes, etc, that don't require any D spec/design change. Only a small percentage of them are "interesting" little not-additive (breaking) changes for D. The ones that I have listed some time ago: Syntax & semantics for array assigns http://d.puremagic.com/issues/show_bug.cgi?id=3971 [module system] Tiding up the imports http://d.puremagic.com/issues/show_bug.cgi?id=3819 Signed lengths (and other built-in values) http://d.puremagic.com/issues/show_bug.cgi?id=3843 [missing error] Array literal length doesn't match Array literal assign to array of different length http://d.puremagic.com/issues/show_bug.cgi?id=3849 http://d.puremagic.com/issues/show_bug.cgi?id=3948 opCast(bool) in classes is bug-prone http://d.puremagic.com/issues/show_bug.cgi?id=3926 Require opEquals/opCmp in a class the defines toHash http://d.puremagic.com/issues/show_bug.cgi?id=3844 automatic joining of adjacent strings is bad http://d.puremagic.com/issues/show_bug.cgi?id=3827 pure/nothrow functions/delegates are a subtype of the nonpure/throw ones http://d.puremagic.com/issues/show_bug.cgi?id=3833 const arguments/instance attributes in conditions/invariants http://d.puremagic.com/issues/show_bug.cgi?id=3856 bool opEquals() for structs instead of int opEquals() http://d.puremagic.com/issues/show_bug.cgi?id=3967 byte ==> sbyte http://d.puremagic.com/issues/show_bug.cgi?id=3936 http://d.puremagic.com/issues/show_bug.cgi?id=3850 A bug-prone situation with AAs http://d.puremagic.com/issues/show_bug.cgi?id=3825 Arguments and attributes with the same name http://d.puremagic.com/issues/show_bug.cgi?id=3878 More useful and more clean 'is' http://d.puremagic.com/issues/show_bug.cgi?id=3981 ----------------------- Few more added in the meantime: Deferencing a dynamic array as pointer http://d.puremagic.com/issues/show_bug.cgi?id=3990 Enum equality to an int http://d.puremagic.com/issues/show_bug.cgi?id=3999 Function pointer/delegate covariance http://d.puremagic.com/issues/show_bug.cgi?id=4000 Tidier management of static variables in pure functions http://d.puremagic.com/issues/show_bug.cgi?id=4031 To avoid struct ctor/opCall conflicts http://d.puremagic.com/issues/show_bug.cgi?id=4053 Steps toward a static foreach (just the first point is enough for now) http://d.puremagic.com/issues/show_bug.cgi?id=4085 Class method hidden by another one warning http://d.puremagic.com/issues/show_bug.cgi?id=4216 x.typeof syntax http://d.puremagic.com/issues/show_bug.cgi?id=4272 Deprecate automatic case fallthrough http://d.puremagic.com/issues/show_bug.cgi?id=4349 Require explicit braces when 'else' is ambiguous http://d.puremagic.com/issues/show_bug.cgi?id=4375 Catch wrong argument<->attribute assignments in methods http://d.puremagic.com/issues/show_bug.cgi?id=4407 Improving the compiler 'in' associative array can return just a bool http://d.puremagic.com/issues/show_bug.cgi?id=4475 "in" operator for AAs in SafeD code http://d.puremagic.com/issues/show_bug.cgi?id=4625 Contravariance problem http://d.puremagic.com/issues/show_bug.cgi?id=4511 Tidier function types http://d.puremagic.com/issues/show_bug.cgi?id=4530 Non-null class references/pointers http://d.puremagic.com/issues/show_bug.cgi?id=4571 Compiler option to port C code or disallow some duplicated C syntax http://d.puremagic.com/issues/show_bug.cgi?id=4580 Lambdas default arguments problems http://d.puremagic.com/issues/show_bug.cgi?id=4664 Troubles with 'auto ref' http://d.puremagic.com/issues/show_bug.cgi?id=4668 Built struct is callable without opCall http://d.puremagic.com/issues/show_bug.cgi?id=4678 Ambiguously designed array syntax http://d.puremagic.com/issues/show_bug.cgi?id=4703 Possible bugs caused by dynamic arrays in boolean evaluation context http://d.puremagic.com/issues/show_bug.cgi?id=4733 Bye, bearophile
Aug 26 2010
next sibling parent Jonathan M Davis <jmdavisprog gmail.com> writes:
On Thursday, August 26, 2010 17:42:18 bearophile wrote:
 Walter Bright:
I just hope you can be realistic about how much can be done about them in
the short term.<

Most of of my bugzilla entries are normal bugs, suggestions for improved error messages and diagnostic, Phobos bugs, enhancement requests, _additive_ changes, etc, that don't require any D spec/design change. Only a small percentage of them are "interesting" little not-additive (breaking) changes for D.

Regardless of what type of bug reports they are, it takes time to deal with them. Yes, some will take longer than others, but if you report them faster than the dev team can deal with them, then it's obviously going to take a while to get through everything that you report (and actually, if you always report them faster than they can deal with them, they'll _never_ get through them all). Now, as Walter said, that doesn't mean that you shouldn't report them, but Walter and company can only do so much so fast. - Jonathan M Davis
Aug 26 2010
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Wouldn't it be better if we had some kind of compile-time block
statement instead of making separate compile-time keywords for every
run-time keyword?

For example, we could reuse static, and instead of code like this from
std.range:

private template MostDerivedInputRangeImpl(R) {
    private alias ElementType!R E;

    static if(isRandomAccessRange!R) {
        static if(isInfinite!R) {
            alias RandomAccessInfinite!E ret;
        } else static if(hasAssignableElements!R) {
            alias RandomFiniteAssignable!E ret;
        } else {
            alias RandomAccessFinite!E ret;
        }
    } else static if(isBidirectionalRange!R) {
        static if(hasAssignableElements!R) {
            alias BidirectionalAssignable!E ret;
        } else {
            alias BidirectionalRange!E ret;
        }
    } else static if(isForwardRange!R) {
        static if(hasAssignableElements!R) {
            alias ForwardAssignable!E ret;
        } else {
            alias ForwardRange!E ret;
        }
    } else {
        static if(hasAssignableElements!R) {
            alias InputAssignable!E ret;
        } else {
            alias InputRange!E ret;
        }
    }
}

We would have this:

private template MostDerivedInputRangeImpl(R) {
    private alias ElementType!R E;

    static {
         if(isRandomAccessRange!R) {
            if(isInfinite!R) {
                alias RandomAccessInfinite!E ret;
            } else if(hasAssignableElements!R) {
                alias RandomFiniteAssignable!E ret;
            } else {
                alias RandomAccessFinite!E ret;
            }
        } else if(isBidirectionalRange!R) {
            if(hasAssignableElements!R) {
                alias BidirectionalAssignable!E ret;
            } else {
                alias BidirectionalRange!E ret;
            }
        } else if(isForwardRange!R) {
            if(hasAssignableElements!R) {
                alias ForwardAssignable!E ret;
            } else {
                alias ForwardRange!E ret;
            }
        } else {
             if(hasAssignableElements!R) {
                alias InputAssignable!E ret;
            } else {
                alias InputRange!E ret;
            }
        }
    }
}

Or maybe use a different name for a compile-time block to not conflict
with static.


On Fri, Aug 27, 2010 at 2:42 AM, bearophile <bearophileHUGS lycos.com> wrote:
 Steps toward a static foreach
 (just the first point is enough for now)
 http://d.puremagic.com/issues/show_bug.cgi?id=4085

Aug 31 2010