const as default for variables

[via Digitalmars-d]

On Sunday, 15 March 2015 at 08:29:36 UTC, Jonathan M Davis wrote:
> Given how restricted const in D is and how many things don't 
> work well with
> it (e.g. it is a royal pain to make ranges work when const is 
> involved), I
> seriously question that this is a good idea. And I agree with 
> deadalnix that
> if we were to change the default, immutabale would make more 
> sense.  const
> has all of the negatives of immutable without providing many of 
> its
> benefits.  Yes, const provides _some_ benefit, but it's pretty 
> limited and
> very limiting. So, if we're considering something like this, 
> why not just go
> straight to immutable and actually get the full benefits rather 
> than get the
> pain with very few benefits?
>
> But really, given how limiting const and immutable are, I 
> seriously question
> that making either of them the default is a good idea - 
> _especially_ when
> you consider how abysmally they interact with ranges and how 
> big ranges are
> for us.
>
> Also, if we're thinking about making a change like this, it 
> would be _way_
> more beneficial to do something like make @safe and pure the 
> default for
> functions rather than make const the default for variables. At 
> least in that
> case we'd be reducing the amount of attribute clutter in the 
> language,
> whereas what you're suggesting would probably make code more 
> verbose in
> general rather than less (due to having to mark so much as 
> explicitly
> mutable), and even if it didn't generally make code any more 
> verbose, it
> certainly wouldn't make it _less_ verbose. Making @safe and 
> pure the default
> would actually help reduce one of the major issues that we have 
> - attribute
> proliferation, whereas this suggestion pushes one of the more 
> limiting
> features as the default.

I concur with Jonathan. There might be an argument for const-ness 
of foreach variables by default, but seeing how that still would 
require additional syntax to opt out, and would be just another 
special case, it's probably not a good idea either.

`@safe` on the other hand looks promising, and is anyway a good 
direction to go.

About `pure`, I'm not sure. That's very limiting wrt I/O. If 
`pure` only implied no access to globals/static locals, it would 
be less restrictive, while still providing useful guarantees. But 
full purity is still worth considering, of course.