On Monday, March 05, 2018 11:38:05 Atila Neves via Digitalmars-d-announce 
> I used to use `immutable`, but gradually came around to only
> using it if I have to send data to another thread, otherwise it's
> too much of a hassle.

Aside from the whole std.concurrency situation, I generally use immutable in
the places where the semantics are the same as const, so it doesn't
generally cause a problem for me. I just prefer immutable in the cases where
it and const are the same, because immutable clearly indicates that the
value never changes, so immutable more closely fits the idea even if const
happens to mean that in that particular case. I agree that using immutable
where you have to do stuff like design objects in a particular way in order
to make immutable work is generally too much of a pain to be worth it, but
at least in those cases, the data can then be shared across threads, and
it's data that doesn't need mutable backdoors, because it only makes sense
to use immutable in that fashion when the object is really designed to never
change state.

I think that the only time that I've programmed heavily in a way that
involves immutability everywhere is when I programmed in Haskell, and that
combined with the fact that Haskell is lazy and completely functional such
that you can't use imperative idioms anywhere made it so that each line of
Haskell code took me more time to write than is the case with any other
language I've used (except maybe batch, because of how insanely error-prone
it is). I think that I'm a better programmer for it, but I'd hate to program
that way normally, and using immutable all over the place would head too
heavily in that direction - though at least D, unlike Haskell, is a
multi-paradigm language and allows you to choose to use a particular idiom
when you think it makes the most sense instead of forcing it everywhere.

- Jonathan M Davis

Reply via email to