Jack Stouffer wrote:

And I sincerely hope they work to fix them before adding in a bunch of new DIPs which will further complicate matters, especially with regard to function signitures.

so far i see that they just like to say: "we won't break user's code", and then silently breaking it, even without deprecation stage.

thank you, guys; guessing when "we won't break the code" really means something is a fun game.

you want the example? `scope` was added to `_compare_fp_t` from "core.stdc.stdlib". thank you for breaking ALL my code that is using `qsort()`. i guess nobody from core dev team really used `qsort()` from libc, so it is ok to break the code with it.

yeah, this was done in git, not in release. but still.

btw, for a short time compiler was unable to build itself at all,
with all that "scope spam". i.e. nobody really cares about travis, or travis cannot properly check commits and is useless (or how else patch that did broke travis builds lands in "master"?)

what i really want to say is that spamming code with shiny new stuff is done... too fast, and tends to disregard "we won't break users' code" mantra. sure, adding new features is fun, i know it, and i like to do it too. but please, let's do it consistently! either drop "we won't break" and start *really* adding features, or stop adding random half-finished things to compiler/druntime/phobos. at least in "master".

p.s.: please, no "don't use git HEAD" blah-blah. it is not about short breakages (which is normal with "bleeding edge"). it is all about lack of consistency and proper... practices. maybe even proper project vision.

p.p.s.: "mostly volunteers", "free", etc. i know. thank you all for your hard work. i appreciate it, and that's exactly why i don't want it to be spoiled by seemingly small and insignificant things.

Reply via email to