What's wrong with D's templates?

[grauzone]

Walter Bright wrote:
>> But you need to allocate this data from a shared garbage collection, 
> 
> You do anyway.

Consider you allocate normal data from a thread local heap, and shared 
data from a shared GC. We will need this anyway to get decent memory 
allocation and GC performance. Especially because the shared GC will 
have a single global lock, and will have to stop ALL threads in the 
process to scan for memory.

Now, where do you want to allocate immutable data from?

a) From the local heap: but then you can't just pass immutable data by 
reference to other threads. It obviously won't work, because the local 
GC may free the memory, even if other threads hold references to it.

b) From the shared GC: but then even only-locally used data like strings 
would have to be allocated from the shared GC! This would work, but 
performance of immutable would be godawful. No way you could do this 
outside of alpha versions of the language.

You could make a) work by copying the immutable data to the shared heap 
as soon as immutable data "escapes" a thread and may be accessed by 
other threads.

What will you do?

>> For large portions of data you could (at least in theory) make it 
>> _actually_ read-only by using mprotect (make the memory pages read-only).
> 
> Compile time checking is better than runtime checking.

Not if the language/compiler gets unusable.

>>> Yes, there was a recently discovered bug which enabled modifying an 
>>> immutable array. This was a bug, and has been fixed. A bug does not 
>>> mean the concept is broken.
>>
>> Sure, but the question is: will all those bugs ever to be fixed?
> 
> Forgive me, but every month 20 to 40 bugs get fixed. You can see it in 
> the change log. I don't understand these complaints.

Frankly, I don't understand how you think that there's no problem. Even 
beginners can hit dmd bugs. Some basic language features are still buggy 
as hell (like forward referencing). Of course only if you actually try 
to use them.

> 
>> Also, how much is this reliability worth if you can just cast away 
>> immutable? It's even exactly the same syntax you have to use for 
>> relatively harmless things, like casting a float to an integer.
> 
> It's not allowed in @safe functions.

"To hell with un- at safe D"?

The current cast syntax, that allows immutable to be casted away, is 
just a damn wide open programmer trap that must be fixed.