Question: When writing Smalltalk code that uses temporaries you write something like:

```
SequenceableCollection>>#swap: index1 with: index2
    | temp |
    temp := self at: index1.
    self at: index1 put: (self at: index2).
    self at: index2 put: temp.

```

I find the syntax for declaring temporaries a bit old fashioned and cumbersome. Actually, is one of the places where you usually stop thinking in your domain and focus in computer (you wrote your method, you are ready to accept the code, but have to "cleanup" your temporaries zone). It is distracting.

Maybe temp declarations are useful for performance? or even declarativeness -which is anyway improved by IDE tuning like syntax highlighting, but I think the `| temp |` could and should be optional. The compiler has all the needed information, or could make the needed assumptions if the user didn't provide a temp declaration (assume the temp lives in the closer environment).

What would be the problems of implementing such a change?

Answer: 
> 
> Would it be possible to make declaration of temp vars optional in
>  Smalltalk?
> 
> 
> 

Sure - the compiler would still know which variables are which *at compile time*, i.e. when you save the method.

> 
> What would be the problems of implementing such a change?
> 
> 
> 

The main problem is that syntax highlighting doesn't cover all cases where things might get... ambiguous:

* What happens when someone else looks at your code who is familiar with Smalltalk but not with your current syntax highlighting settings? Remember that you should always write code for future readers, not just for yourself.
* What happens if you view your code outside your IDE, e.g. when you're developing in Seaside and modify code (that still lives in your IDE) directly via the browser?
* What happens when you take your code out of your IDE, e.g.
	+ to answer a question here on SO,
	+ for your blog post,
	+ in an email to a colleague,
	+ to export to a different flavour of Smalltalk?
* What happens if, after using an "undeclared temporary variable" in a method, you add an instance variable to the class that has the *same name*? Does the compiler have to go through all methods in that class and its subclasses and ask you which one you meant? (Conversely, what happens when you remove an instance variable that's being used?)

TL;DR: **Finding something "old-fashioned", "cumbersome", or "obtrusive" (as much as I may agree with you) does *not* trump clarity and disambiguation.**

Having to declare temporaries comes with the territory, so to speak. Additionally, I don't think a quick "cleanup" of your method before you accept it is a bad thing.
There are no technical problems - it would be trivial to change the compiler, technically. 

But it would be a maintenance and debugging nightmare, as already pointed out by others: what happens if a same-named variable is later added in an outer scope (and that might be an instvar way up in the inheritance hierarchy)? Also, what if you simply have a typo, and a temporary was not your intention, but you actually wanted to access some existing variable?

Having programmed for a long time (and in languages which do automatic variable definition), I would not want this. It might be ok for little 10-liner scripts, but not for big programs which have to be maintained over a long time. As Bert pointed out, workspaces usually do this for you and that is fine, but not in methods which go into production code.

I remember an old story about a fortran program which crashed, because the programmer wrote "do10i=10.20" instead of "do10i=10,20" and got a new variable named "do10i" assigned to 10.20 instead of a do-loop. He would have been warned, if he had to declare variables first (admitted: fortran was an ugly language then, but you get my point, I guess).