D safety! New Feature?

[ag0aep6g via Digitalmars-d]

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.