Am 28.01.2022 um 23:57 schrieb Jordan LeDoux <jordan.led...@gmail.com>: > > On Thu, Jan 27, 2022 at 12:24 AM Christian Schneider <cschn...@cschneid.com > <mailto:cschn...@cschneid.com>> wrote: > > My issue with this is that while it seems to work towards the goal of "fail > fast" it does not completely fulfill its promise. > > > Pardon me, but this argument seems rather impotent. Only fully realized > features are allowed? What if there is not agreement on the details of some > of the edgecases? Something better should be rejected because it's not > something perfect?
I was probably too brief there, let me elaborate a bit. An error on reading an undefined variable does the "fail" part. And it partially delivers on the "fast" part as it fails at the first access, not at a later point. But, and that was my point, it is still failing at runtime, maybe long after deployment if it is in an obscure code path. If a static analyzer manages to catch it at development time then that is a lot better. This has an impact on how I evaluate the positive effect of error-on-undefined and so far my conclusion was a net-negative compared to the current situation. Side-note: An additional downside of having the increased safety net on reading undefined variables can be that developers think they do not need to have other checks like a static analyzers which might do an even better job to make their code better. But that's not my main point. - Chris
