On Wednesday, 2 October 2013 at 13:09:34 UTC, Daniel Davidson
wrote:
I'm reviewing Ali's insightful presentation from 2013 DConf. I
wonder has he or anyone else followed up on the concepts or
formalized some guidelines that could achieve consensus. I
definitely agree it would be helpful to have a 50 Ways To
Improve Your D. The first thing I'd like to see is a set of
guidelines on mutability along the lines he discussed in his
talk. But as it stands, I don't know if there was any
finalization/consensus. For instance, from the first two
guidelines at the end (after several iterative reconstructions
of those guidelines):
1. If a variable is never mutated, make it const, not immutable.
2. Make the parameter reference to immutable if that is how you
will use it anyway. It is fine to ask a favor from the caller.
...
If you follow (1) exclusively, why the need for immutable in
the language at all?
Maybe it is a philosophical question, but where does
immutability really come from? Is it an aspect of some piece of
data or is it a promise that function will not change it? Or is
it a requirement by a function that data passed not be changed
by anyone else?
The two keywords cover all in some sense.
I found the end of the video amusing, when one gentleman
looking at a rather sophisticated "canonical" struct with three
overloads for 'this(...)' and two overloads for opAssign, asked
if all those methods were required. I think there was back and
forth and head-scratching. Another asked if the language
designers were happy with the resultant complexity. Naturally
the answer was yes - it is a good mix. If that is the case I
wonder if the reason is they don't write software in D like Ali
was looking to develop. I imagine standard library code is much
more functional than OO by its very nature. My money says you
will not find a struct S constructed like Ali's in the wild -
it is just too much boilerplate. But surely they have their own
guidelines/approaches.
By posting this I am not looking for a single answer to the
simple question above as it is just one of many questions in
the set of "how do you choose among the options in general". If
you have such guidelines - please post them.
Thanks
Dan
After trying for several days to use immutable with types
containing some mutable aliasing I have come to the conclusion
that maybe rule number one should be:
If you have a type that has now or may ever have in the future
any mutable aliasing (e.g. inclusion of T[] or T1[T1] where Ts
are mutable) do not ever use the immutable keyword in any context
as things just break down.
If you have had more success with a immutable with types
containing mutable aliasing and can share your success story that
would be great.
As D is growing are there any out there yet offering support
services?
Thanks,
Dan
