D safety! New Feature?

[Mark J Twain via Digitalmars-d]

On Friday, 5 August 2016 at 21:12:06 UTC, ag0aep6g wrote:
> 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" */
> }
> ----

wow, that seems like a huge design issues.

Change one value to double though and it won't work. It's not 
general and seems to be a design flaw. It is not proof of 
anything in this case though. Why? Because an Queue might not 
have the same size as an ImmutableQueue and your "proof" only 
works when they are the same size.

>
> [...]
>> 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.

What kind of example? I have already given examples and proved 
that there is a functional difference. I will not continue this 
conversation because you refuse accept that. First you haven't 
given your criteria for me to prove anything to you to satisfy 
whatever it is you want. Second, I'm not here to waste my time 
trying to prove the merits of the tool. Again, either use it if 
you feel like it does something or don't. The method is not 
flawed in and of itself. It works(if it didn't, someone would 
have probably already shown it not to work).

All you can do is assert a negative, which you can't prove 
yourself. So we end up chasing each other tails, which I refuse 
to do. If you want more proof then it is up to you, not me. I 
have my proof and it is good enough for me.