If D becomes a failure, what's the key reason, do you think?

[BCS]

David Medlock wrote:
>> c) Are passed allocated objects, which they are *NOT* allowed to 
> manipulate."
> 
> These are called interfaces, and are quite do-able in D.
> 

interface fun
{
	int look();
}

interface fig : fun
{
	void touch(int);
}

interface foo : fig
{
	void other();
}

foo GetTouch();
foo GetNoTouch();

Now how do you keep people from not calling touch on an instance of foo 
returned from GetNoTouch()? I'm sure it can be done with some 
rearranging, but why make the solution so complicated?

for that matter what about an int* that shouldn't be modified? Objects 
are not the only ref type in D.

>> d) Allocate and return objects/data that shouldn't be manipulated by 
> the user."
> 
> Such as what?  Nothing in D stops the two cases above.
> 
> 
[...]
> 
> Not having const is not a limitation- its a semantic addition.  Whether 
> its a feature depends on what you are trying to do.
> 

And anything that can be done with a computer can be done in asm (or a 
Turing machine) but thats not the point.

>>
>> What does "HUGE" mean to you, anyway? Perhaps you'd care to spell out 
>> those benefits you know of, so we can perhaps quantify your use of 
>> that adjective?
> 
> 
> HUGE meaning my workflow/productivity increased.  The computers work for 
> us, not the other way around.  If it doesn't make me write programs 
> faster or better, it isn't a feature.
> 

The addition of the concept of const _should_ allow the compiler to find 
errors of something changing something it shouldn't. This should 
decrease the occurrence of a whole class of bugs (that people seem to be 
worried about) and as a result let people spend more time thinking and 
doing other things. The only cost that I can see of adding const is a 
butch of compile time errors (that are easy to fix compared to run time 
errors) and the requirement that code be structured so that code that 
needs to changes stuff has mutable references to it. This would, I 
expect, requirer just a much thinking as the program would without 
const, but would requirer the thinking to be explicitly stated in a way 
the the compiler can check to some extent.

> The advantages always boil down to one of:
> 1. Multithreaded code - does not help unless you get rid of pointers and 
> delegates!
> 2. Performance   - much better potential than const in this area.
> 3. Ref counting  - popular in the 80s....pretty much proven useless for 
> 85 percent of real tasks, and its not thread safe.
> 
> Anything outside of those things...?

"I can safely assume that passing this reference to this function won't 
get it changed."