Head Const

[ZombineDev via Digitalmars-d]

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/xfjoktyjtoojhszrlugi@forum.dlang.org 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.