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

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

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