const?? When and why? This is ugly!

[Andrei Alexandrescu]

Burton Radons wrote:
> Andrei Alexandrescu Wrote:
> 
>> Burton Radons wrote:
>>> A more accurate way would be for the string type to be "const
>>> (char) []", and for functions which retain strings that can't
>>> change to take "invariant (char) []". That makes pretty good
>>> claims about the nature of the string, but it would clearly
>>> result in lots of cast management.
>> I use that all the time, it's a great idiom. What cast management
>> needs to be done? What I need to do is occasionally insert an .idup
>> on the client side because the callee wants a copy. So that's that.
>> 
> 
> So long as the object definition of string is "invariant (char) []",
> I can't guarantee anything about the nature of the object because you
> need to cast to "invariant (char) []" to be able to interface with
> any API.
> 
> The good side is that when I changed it to be defined as "const
> (char) []" only one line of code made a squeak. That gives me solid
> actionable information. If an API is declared as istring, then
> whatever you give it must not ever change. If an API is declared as
> string, then whatever happens in there, it won't change the data.
> Pretty good!

I have trouble following what you're saying. If what you're saying is 
essentially that in char[] is a better parameter definition than string 
for functions that don't need to escape their string argument, then yes, 
you are entirely right.

So what I recommend is:

void foo(in char[] s); // foo looks at s, doesn't escape it
void bar(string s); // bar needs to save s
void baz(char[] s); // baz needs to change s' contents

>>> I think all these problems boil down to the fact that invariant
>>> tells you about the container rather than the object itself; but
>>> whether the object actually is invariant is totally independent
>>> of the container. The genius of D 1.0's const is that it makes an
>>> actual, actionable true statement about the object. That was a
>>> HUGE benefit. This tries to push it back into C territory and I
>>> don't think it works.
>> I don't think I understand most of this, possibly because some of
>> it is wrong. D2's immutable does offer a solid guarantee about
>> what's going on and offers a programming model that makes it easy
>> to write correct code without undue aliasing. So C doesn't quite
>> enter into the picture there.
>> 
>> Objects in a container being invariant tell a lot about the
>> container. That property makes the container shareable without a
>> risk.
>> 
>>> I don't buy that this is going to lead to any MP bonuses either.
>> Wait and see.
> 
> I don't need to wait and see when twenty years of "hinted
> optimisation" have had predictable results. If the programmer can set
> an incorrect state doing something which he's forced to do, then any
> compiler which uses this state as an actual description about the
> situation will cause problems because the compiler's opportunities to
> apply these optimisations will shift over the course of the
> development of the program. Code works, add one line, code doesn't
> work. Code works, try it on another machine, code doesn't work.

You are completely, thoroughly losing me. I can only assume you are 
misunderstanding the role of const and immutable in manycore programming 
and build from there.

> The only way I can see this working is if the compiler really did
> have a good idea about the nature of the state, at which point the
> programmer's statements are completely superfluous. That's not
> coincidentally exactly how we do these optimisations now: determine
> whether the state is in such a way that we can do this safely, and
> only then actually apply the optimisation.
> 
> That can involve automatic MP of a sort - I understand that's the way
> the C-based MP systems work, where you tell it that the state of the
> program is such and such before letting it go ahead.
> 
> Fully automatic unambiguous effective parallelisation requires that
> everything the programmer says is true. It's not something that can
> be stuffed into a language with pointers and external API calls. If
> you think you can do that, fine. But you haven't, and nobody else
> has, to my knowledge.

I continue being lost. Words assemble in phrases, phrases assemble in 
sentences, sentences parse properly, but I can't understand one thing. I 
need to defer a response to others.


Andrei