D safety! New Feature?

[Chris Wright via Digitalmars-d]

On Sat, 06 Aug 2016 01:57:50 +0000, Mark "J" Twain wrote:
> wow, that seems like a huge design issues.

In practice, it's not a problem. In a language supporting low-level 
operations, you do sometimes need a reinterpret_cast. And since there's 
no other useful cast you can do with a D struct...

The casting rules *are* moderately complex, though, in order to do the 
most useful thing at all times.

> Change one value to double though and it won't work.

With your own example of MutableArray and ImmutableArray, the two structs 
need the same fields. You even started out with a mixin to define common 
fields.

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

An example demonstrating clearly the difference between this design 
pattern immutability and the already defined language construct. This 
example should demonstrate that you know how immutability works in D 
today.

You haven't demonstrated much knowledge of D so far in this thread. 
Specifically:

* You think a function can trivially reuse memory across invocations, but 
only if manually released, and releasing memory allows it to be stack-
allocated. This ignores garbage collection, recursion, memory safety, how 
the stack works, and how to make this feature practical to implement.
* You use a 'global' keyword.
* You are using a nonstandard code style.
* You misspelled `scope(exit)`.
* You believed that you can call on an immutable object methods that are 
not marked immutable, and that the compiler would produce an error at the 
site of mutation, which would be quite impossible. Consider the following 
code:

extern(D) void foo(MyObject o);
void main() {
  foo(new immutable(MyObject));
}

With your idea of how immutability is enforced, the compiler wouldn't 
know whether the code is valid or not.

> I have my proof and it is good enough for me.

But you posted here to suggest that people use this pattern. You went so 
far as to hint "compiler support would make this nice". And then when 
people pointed out that there's already compiler support for this and 
it's better than what you suggested, you argued with them!

If you had said that you had looked at the builtin const/immutable and 
still preferred your model, well, it's your code. But instead you tried 
to sell us on your idea.