search

google / wuffs

Wrangling Untrusted File Formats Safely
Other
4.07k stars 129 forks source link

reasoning behind restricting vars at the top of functions #19

Closed mvdan closed 5 years ago

mvdan commented 5 years ago

This was done in cbe19f50e08856fb438756ac3a75aed6cc92e2ac - I'm curious if there was a particular reason behind it. I presume it's to simplify generating C89 code?

I'm not directly opposed to the restriction, but it does make code a bit unreadable. Perhaps it's because I've been writing a lot of Go in recent years. For example, see the diff in https://github.com/mvdan/zstd/commit/7f8b358c2211ad149f3913289b07ab5e54e36bfa.

nigeltao commented 5 years ago

It does simplify the codegen (which outputs C99, not C89), both in terms of the Go code that is "the compiler" and the C code that is "the output". It also avoids having to specify or otherwise worry about reading from variables before they're first assigned to.

At some point in the future, we could make the compiler smarter (i.e. more complicated) by allowing vars elsewhere in the function again. But I'd like to try "vars at the top" for now to see how painful it really is.

One of the things about Wuffs is that it favors clarity (and specifically, regularity and lack of ambiguity) over convenience. For example, Wuffs did not (and still does not) let you shadow local variables, even though that's definitely convenient in Go (and other languages). Similarly, Wuffs makes you spell out this.x, args.y or base.u32 where other languages let you say just x, y or u32. I think "vars at the top" is consistent with that philosophy.

mvdan commented 5 years ago

Fair enough, thanks. Any tips to make "vars at the top" less painful, besides breaking up large funcs into smaller funcs?

nigeltao commented 5 years ago

I don't have any tips, sorry.