On Wednesday, 16 October 2013 at 19:12:48 UTC, Dicebot wrote:
On Wednesday, 16 October 2013 at 19:06:06 UTC, Daniel Davidson
wrote:
I don't understand how it could be fine. As code grows it
would lead to people not adding useful members like history
just because of the huge repercussions.
struct User {
immutable(Foo) foos;
}
How can I as a user adapt to that change? Before the change
assignment worked equally well among all of Mutable,
Immutable, Const. After that change any `foos ~=
createFoo(...)` would require change. And it is not clear what
the change would be.
I think any usage of immutable with types/entities not
initially designed for immutability is an potential mistake and
in that sense it is good that change has broken the user code.
Same goes for operating on immutable entity in generic code as
if it is a value type without actually checking it via
introspection.
I don't disagree. Now, what does it mean to "initially design for
immutability" and what are the guidelines. I thought that was
kind of what we were talking about here. How to effectively use
const and immutable. If the rule is - don't use immutable unless
you have immutability in mind for your design, ok. Maybe take it
a step further...
How about this - show a good use of immutable in any context
where mutable aliasing (e.g. AAs) are in the mix. If the response
is there are none, it is just too hairy of a proposition then
something is wrong.
One general idea that was presented by Ali is that an immutable
parameter means that not only are you guaranteeing that you will
not change your data, but also that no one else, even in another
thread will. That sounds appealing. After all, who doesn't want
the data they are using in a function to not change from
underneath them? Suppose you have highly structured, deeply
nested reference data you read from a nosql DB. Surely there is
opportunity and some benefit to use immutable? The result of the
query is just a read only data source. But then that data will be
consumed - presumably by functions with either immutable or const
parameters. If all signatures use const then when can you benefit
from the fact that the data is really immutable (by the time it
gets to a function with const parm the fact that it really was/is
immutable is lost.
