Bartosz Milewski Wrote: > Steven Schveighoffer Wrote: > > > > Bottom line: if a function isn't supposed to change the buffer, the > > signature should be const for that parameter. It's one of the principles > > of const, and why it's in D2 in the first place. I'd explain to the coder > > that he is wrong to expect that modifying a buffer in a function that > > isn't supposed to modify a buffer is acceptable (and hopefully he gets it, > > or else I don't have time to deal with people who insist on being right > > when they are not). > > > > BTW, in my experience, the newbie expectaction of ~= is usually that it > > modifies the original even when it doesn't, not the other way around. > > > > The guy insists that the reallocation happens in the quote function > (otherwise there would be stomping), so no sharing happens and the original > is not modified. He tested it on a variety of inputs! I'm not totally making > it up--I had this kind of arguments with C++ programmers. You tell them that > it's safer to use const and they laugh at you. "My code works, why should I > change it!"
C++ const is kind of a joke :) But in any case, it's trivial to come up with a case that causes buffer issues. If he insists on a test case, then I'd give him one. Programmers like this don't last long at companies. I had a coworker once who insisted that a bug he was working on was going to be impossible to fix, so there was no point in working on it. My boss said that if he (the boss) could fix it, the coworker would be let go. My boss fixed it in one day. And there are *tons* of logic errors that don't cause bugs for most inputs, I don't see why we are focusing on this one case. > > > >> Second, the optimizer cannot do simple math optimization on src.length > > >> -= > > 1 and src.length += 1 because length is a property, not a field. Setting > > the length calls a function, which cannot be optimized out. > > You are again resorting to implementation. I guess in the current > implementation it's true that the compiler will indeed insert a call to its > internal function. But the language spec does not proscribe that. > Sure it does. It says that setting the length may reallocate the array to hold enough space. How do you do that without a function call? > Would you also argue that this optimization is incorrect? Changing: > > a.length += 2; > a.length += 3; > > to: > > a.lenght += 5; To the developer? no. To the compiler? yes. The compiler cannot know what affect it will have by making this optimization, it does not know what the underlying function will do or the semantic meaning of those statements. What if adding to a.length outputs it's argument? Then the optimizer would have changed the output from 23 to 5. But the developer who knows the semantic meaning can make the optimization change. > > I'm not saying that this is an unsolvable problem. I'm just showing how hard > it is to reason about D arrays. > I will agree that D arrays are hard to explain, I've had my share of training sessions on IRC. It's not an easy concept to get right off, but the benefits of doing arrays this way are huge. -Steve
