Tom Christiansen writes: > >To resolve this bug I would like to see one of two things happen: > > It's not a bug. It may not be a feature, but it's not a bug. > The best way to resolve it is with a doc patch. Giving the user incorrect data is a bug. There's no "." in that line of code, so even though it optimizes to a line that contains ".", it doesn't help the user unless he/she knows that. Most Perl programmers don't know much about the way Perl works internally and wouldn't necessarily assume that it optimizes things that way. A doc patch would help a little, but I don't think that's enough. Simply saying "use of uninitialized variable in line xxx" is fine, but once you start trying to tell the user what operator went wrong, you have to be accurate when you do so. > >1. Remember whether we are doing variable interpolation or if the user > >actually spelled it out with '.' between each part of the string, and > >give either "... in concatenation (.)" or "... in string interpolation" > >as the warning, or > > I'd like to see the patch for that. Shall we invent new opcode > types and just toss compiler optimizations to the wind just because > people are dumb? I'm sure the patch for that would be a pain in the ass to implement. It might be the wrong trade-off in terms of performance. I just think that if you're going to try to tell the user what caused the error, you should tell them what actually caused it. And since the user didn't use '.' in that spot, it would cause a lot of confusion trying to hunt it down. Also, remember that novices are often told to turn on warnings, and so they would be the most likely to be bit by this problem. --Bill. -- William R Ward hermit@bayview.com http://www.bayview.com/~hermit/ ----------------------------------------------------------------------------- The secret of being creative is making something that's not very new but just a little bit different in the right direction - Marvin Minsky