On 08/05/2016 09:39 PM, Mark J Twain wrote:
In the case of ImmutableQueue, There is no Enqueue!

See, there is a difference between "not callable" and "does not exists".

Ok, but what cool stuff is enabled by "does not exist" that doesn't work (as nicely) with "not callable"? As far as I can tell, there is no difference in practice.

[...]
`immutability` only logically makes something immutable, as it can
easily be proved. One can cast out immutable and mutate very easily(take
address, change values).

Casting immutable away and then mutating is not allowed by the language. It has undefined behavior. After doing it, the program may see the old value, it may see the new value, it may crash, or it may behave completely crazy.

Some example code that shows different outcomes of mutating immutable data:

----
void main()
{
    import std.stdio;

    immutable int i = 1;
    * cast(int*) &i = 2;
    writeln(i); /* prints "1" */
    writeln(*&i); /* prints "2" */

    immutable int* p = new int(3);
    *(cast(int*) p) = 4;
    writeln(*p); /* prints "4" */

    immutable(char)[] s = "a";
    (cast(char[]) s)[0] = 'b'; /* segfault on Linux */
    writeln(s); /* prints "b" on Windows */
}
----

That's not a valid D program at all, of course. All of the mutations are invalid.

`Immutable` cannot be cast because there is no
type relationship.

You can cast between completely unrelated types no problem:

----
struct MutableSomething
{
    int value;
    void mutate(int newValue) { value = newValue; }
}

struct ImmutableSomething
{
    int value;
    /* no mutate method here */
}

void main()
{
    auto i = ImmutableSomething(1);
    (cast(MutableSomething) i).mutate(2);
    import std.stdio;
    writeln(i.value); /* prints "2" */
}
----

[...]
What I would say to you is, either try it on some examples, or don't.

I'm asking you for an example, because I don't see the point of it.

I'm not trying to take away your favorite blanket... just present
another tool for solving some problems. If you don't like it, that's
fine, don't use it. Don't get upset, it won't affect your world if you
don't want it to. For those that see some use out of it, use it, else
don't. Simple as that.

I cannot see any benefit in using your tool rather than plain immutable, which is why I'm asking for an example that shows the benefit. By now, I think there just isn't any.

I think you have (or had) some misconceptions about immutable and casting in D, so you came up with something that's supposed to be stronger. But D's immutable already seems to be as strong as your construct.

D already rejects calling a mutating method on an immutable object, and it also disallows casting immutable away and then mutating. Breaking things with a cast is always possible, even with your unrelated types.

Please don't take this personally. I don't mean to put you down. I just think your ImmutableFoo thingy doesn't buy you anything over immutable Foo.

Reply via email to