On 11/28/2012 12:05 PM, Joseph Rushton Wakeling wrote:
On 11/28/2012 12:48 PM, Manu wrote:
If D stabilised on exactly the feature set it offers right now (or
even 3 months
ago), I wouldn't be interested. The lowest level is brittle, and the
high level
is still missing a couple of little details (rvalues -> ref is the key
one for me).
D's fluidity is actually one of it's biggest selling points as far as I'm
concerned. D seems to accept that mistakes can be fixed and
improvements can be
made, and it should embrace that to an extent, or you end up with C++
long term.
I think the best approach is one that others have suggested, 2 branches,
'stable' which is maintained for 6-12 months, and only receives
non-breaking
fixes after they've been tested for a while, and 'dev', which users
accept may
receive breaking changes at any time. Those users will be happy to
adapt their
code as the language moves forward, as I am.
I'd agree but with one caveat -- how do you handle the case of the
standard library, or indeed any other library?
Obviously, every library developer can choose between maintaining a
version that works with stable only; maintaining a stable and
'bleeding-edge' version; or just bleeding edge. Presumably for Phobos
you'd choose the second of these. But then, how do you handle _new_
functionality that may or may not depend on breaking changes to the
language?
Given that Phobos is still a moving target with new functionality being
added on a regular basis, it could be a bit of a disappointment to have
to wait as long as 6 months to see the latest new features.
The same also applies to the downstream compilers like GDC and LDC -- it
would be frustrating to have to wait so long to see new functionality
available here. One way to handle that might be to first do the work to
properly separate out the frontend, so that updates can be merged
immediately into GDC/LDC's dev versions rather than having to wait for
each release.
Finally, even in dev I think it would be useful to still have some
formal notice of deprecation, so that there's time to anticipate
changes. I'd rather not just wake up one morning and find that my code
no longer compiles!
A new module in Phobos is highly unlikely to break anything, So I would
assume that this would count as a simple bug fix and be merged.
