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.