Bram Moolenaar wrote: > Ben Schmidt wrote: >> While working on the Float printing function, I also noted an odd Vim >> behaviour: it won't let you assign a Float to a variable that was >> previously a Number, and vice-versa. Or for that matter, it won't let >> you change the type of a variable at all with an assignment. >> >> The trouble is in the set_var() function. Consider the following patch >> (it is applied to my patched Vim, so line numbers will be ridiculously >> different to the original, probably, but should apply cleanly and can be >> found manually by :tag set_var): > > Thanks, this makes sense. Except that we should not allow conversion > between String and Float.
OK. I see. So the allowed changes are only those that are done automatically anyway. >> The first hunk patches the variable type mismatch check so that it >> allows floats to be included as allowed type changes. >> >> However, why is this check there? I don't see any reason changing a >> variable type to or from a list, dictionary or function reference would >> cause any problems either. References are correctly updated by a call to >> clear_tv shortly after the check, and tv and v->tv could not reference >> the same variable and include a change in type, so there is no chance of >> freeing a structure that is about to be used. Couldn't the check be >> safely removed and thus enable variables to be freely assigned values of >> new types? > > It's called sticky type checking. Not everybody likes it, but that's > the way it is. I guess it has analogies with languages such as C that use static typing. But does it actually have any benefit in Vim script? I can't think of one. I mean, do people actually see this error and think, "I made a programming error, and I'm glad I found it," or do they see this error and think, "Bother, I've got to work around Vim's type restrictions" (and probably assume it's an implementation issue that can't be avoided)? I know which I think, and was a bit astonished to find no technical reason for it! If it truly has no benefit, why keep it? Removing it would be like adding a new feature with essentially no effort! Perhaps some others could let us know their experiences/thoughts on this? Still, it is a pretty minor issue; it's easy enough, though messy, to work around. >> The second hunk seems to be purely an optimisation, avoiding an >> unnecessary call to init_tv in the else part. It applies equally to >> Floats as Numbers, I think. > > Yes. OK, cool. Cheers, Ben. --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
