On Monday, September 23, 2013 13:49:59 Daniel Davidson wrote:
> > But if your concern is client code messing with your member
> > variable, then
> > don't give them access to it in the first place.
>
> Not quite as much messing with the member as messing with what it
> points to. In the setup - ri
On Monday, 23 September 2013 at 03:51:41 UTC, Jonathan M Davis
wrote:
Doesn't using immutable there present the same problem as with
the slice? S is no longer assignable. But who would recommend
not
using immutable in this case if you want aarr to be stable. If
you do not use immutable then who
n any of the elements in those arrays. Best case, you can
mutate their members that aren't const or immutable, but all of their const
and immutable members are stuck referring to the value in S.init.
Anywhere that involves S.init stops working properly, because you can't change
any S
On Sunday, 22 September 2013 at 20:17:03 UTC, Jonathan M Davis
wrote:
If you have
struct S
{
immutable int[] arr;
}
then arr can never be assigned to, so a variable of type S can
never be
assigned to. But if you have
Yes - it (arr) can never be assigned to. That is the idea. It has
alr
On Sunday, 22 September 2013 at 16:15:09 UTC, Daniel Davidson
wrote:
[...]
3) Also, is storing immutable(STUFF) in a struct in the
general
case (as opposed to just this one) useful or silly?
[...]
I don't really understand the _tail-const_, _tail-immutable_
argument. Why is _tail-const_ f
On Sunday, September 22, 2013 18:15:08 Daniel Davidson wrote:
> In this thread
> (http://forum.dlang.org/thread/uvhwkgljavskqfueq...@forum.dlang.org)
>
> I asked this:
> >> 3) Also, is storing immutable(STUFF) in a struct in the general
> >> case (as opposed to just this one) useful or silly?
>
>
In this thread
(http://forum.dlang.org/thread/uvhwkgljavskqfueq...@forum.dlang.org)
I asked this:
3) Also, is storing immutable(STUFF) in a struct in the general
case (as opposed to just this one) useful or silly?
Johnathan M Davis replied:
As soon as you have a const or immutable member i
