On Thursday, 14 June 2012 at 11:11:57 UTC, Jonathan M Davis wrote:
I haven't had the chance to look over your code yet, but this
looks
_seriously_ suspect. Casting to and from immutable or cast away
const are
things that should be done _very_ rarely. One of the few times
that casting to
immutable makes any sense is when you need an object to be
mutable while you
put it together and then immutable afterwards. But when you do
that, that
reference or pointer is the _only_ reference to that data. e.g.
auto func(size_t numElems)
{
auto arr = new int[](numElems);
foreach(ref e; arr)
//do something to initialize e
return cast(immutable int[])arr;
}
Taking a function's parameter (which came from who-knows-where)
and casting it
to immutable is almost certainly a terrible thing to do. If
there are _any_
other references to that data, you will have bugs. immutable is
supposed to
guarantee that the data is _never_ altered. So, when you cast
something to
immutable, you're telling the compiler that it's okay to treat
that data as
immutable and that you will _not_ have any mutable references
to that data or
alter it in any way. If you do, you'll be breaking the
compiler's guarantees.
Ideally, you would always construct immutable objects as
immutable rather than
creating them as mutable and then casting them to immutable,
but that's not
always possible.
And taking your payload, which is immutable, and casting away
immutable when
you return it from front is truly bad. Casting away const or
immutable and
then mutating that object is _undefined_ behavior. Do _not_ do
it unless you
have to and know what you're doing.
These stackoverflow questions may help you understand better:
http://stackoverflow.com/questions/4219600/logical-const-in-d
http://stackoverflow.com/questions/10364837/why-do-i-have-to-cast-this
- Jonathan M Davis
OK, clear. Thanks!
I was thinking that casting is bad here, but wanted to give the
user ability to pass any object inside constructor. Now I see
that this is a bad idea given transitivity of immutable.
In .NET readonly applies only to fields inside objects preventing
assignments to them from other places than constructors. But I
can assign another instance of an object with readonly fields to
the same variable. Then I can pass that instance to some
constructor and assign it to a readonly field.
How to achieve the same in D? As far as I understand, it is not
possible for structs with immutable fields, and it is not clear
for me about classes.
In other words:
Does a variable always point to the same place in memory and
assigning to it simply copies data to that place? I don't
understand whether it is possible to make it point to another
place. That would be a mutable variable pointing to a type with
immutable fields. After that I want to assign an instance of that
type to an immutable field in constructor. Can I do so, or that
would be bad?
