D future ...

[ketmar via Digitalmars-d]

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.