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
