but it throws a syntax error unlike C++, which has vastly different concepts of variables, scoping, closures, and capturing. The parser would still need a drastic change. It’s easy to say it “doesn’t have to be complicated”, but if it were, then we wouldn’t have open issues about feature consistency between our existing function syntaxes.
Not just that macro, you would need to edit every macro that makes a function block. I couldn’t even guess at what happens to macros that make multiple.
That doesn’t imply you can effortlessly repurpose syntax from other languages and expect the same perks. All the languages you named are statically typed and their proven features are fundamentally difficult to replicate in dynamically typed languages that made different tradeoffs.
Making new rules that are convenient only for specific cases results in feature bloat, a common complaint about C++ in fact. Instead of training wheels pointing in all sorts of directions, it’s easier for people to learn better general practices. Making edits to a function without knowing what else happens in it is not something that should go on for long.
Manual specification is always tedious, and you just found one example where one kind of manual specification happens to be convenient. That won’t translate to the general case. The fact that typing local everywhere is tedious is exactly why local scopes share variables automatically.
This name being similar to let is misleading because you are specifying what can be borrowed rather than what isn’t. Something like alllocalexcept maybe. But I’ve mused about a very similar thing before and realized it gets nastily complicated to work out nice scoping rules in general, and ultimately nothing was simpler than the status quo and common sense.