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 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. 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.
