On Tuesday, 16 February 2016 at 10:17:05 UTC, Jonathan M Davis
wrote:
On Tuesday, 16 February 2016 at 10:06:12 UTC, ZombineDev wrote:
Another bonus to introducing the mutable keyword is the option
to make everything immutable by default (in a future version
of D) and allow the users to have mutable objects only if they
use the mutable keyword.
While some folks do bring that up from time to time, I think
that it's pretty clear that that would be so restrictive that
it would risk killing D. As it is, many programmers avoid const
altogether, because it's too restrictive.
Not if immutable by default is opt-in - read below (my second
paragraph).
Heck, ranges are designed in such a way that they require
mutation to work, and they're everywhere.
Ranges are not a hard problem, they're more of a too much good
code written with them to be worth the breakage.
Since ranges are mostly meant to be cheap value types, we can
just make popFront return a new range, just like slicing an array
slice returns a new slice. However for this to work we would need
to rewrite a ton of std.range, std.algorithm, etc. so it probably
won't provide a good enough cost/benefit ratio.
I'm working on a different proposal to generalize ranges to
support push data flow model, in addition to the current
pull-only, which would allow them to be used for processing async
data (e.g. comming from I/O or another thread performing
expensive computation for each element) in a **non-blocking**
way. Processing async data with the current range primitives
implies polling/blocking on popFront or front, which is a
performance killer and diminishes the value of composition.
I hope my proposal would provide enough value to be included in
phobos as an alternative to the current InputRange primitives. If
it proves to be good enough, maybe it would be worth adding new
versions of most of the current range algorithms/transformations
that leverage the new prmitives.
I haven't yet figured out the best way to bring these API ideas
from Clojure and C++ to D (see
http://forum.dlang.org/thread/[email protected] for more info on me exploring one possibility of using higher-order functions), because there are plenty of ways to do this which I want to explore, but I hope to have something concrete in a couple of months.
immutable has its uses to be sure, but I don't see how it's
anything but a pipe dream to expect any version of D to be
immutable by default. For most programmers, it would be way too
annoying and way too verbose, because they'd be forced to slap
mutable on most everything.
Immutable by default has two sides:
1) The programmer writing the code
2) The user of the code
The change to immutable by default should only affect 1). 2)
should be the same as if currently you make something immutable.
This means **no code breakage**.
A good way forward, IMO, is to be able to indicate at the
beginning of the module your general preferences e.g. immutable,
@nogc, pure, non-virtual by default. This should affect **only**
the current declaration scope, just as if you have put `nothrow:`
at the beginning. The only thing that's needed is a way to revert
this. The proposed solution is `pure(false)`, `final(false)`,
etc., which Andrei already approved.
Regardless, there isn't much point in planning for a future
version of D. We don't know what we're going to want to do at
that point, and if we're actually willing to break backwards
compatibility in a serious way, what D2 looks like doesn't
really matter much for D3. And we don't even know whether there
will ever be a D3. What matters to us now is what we do with D2
for making it a good language now and not what we may or may
not do with a future version of the language. Planning for D3
now would be like planning for D when working on finishing up
C++98.
- Jonathan M Davis
I agree. I think we should focus on features that have strong
benefits and don't break backwards compatibility. There are
plenty of stuff to explore in this area. From what I've read, the
D1/D2 and Phobos/Tango devisions was hurtful for the community.
We should instead focus on unitying and improving what we already
have in order to bring real benefits to our community.
