On most real life projects, the speed of development is easily worth an occasional corner case bug with an unexpected nil value … except when it isn’t.

Do not pass arguments right into subshell, it's as unsafe as eval.

I really hope they keep breaking it. Being the lead on a library for several years, most of the forced refactors were pretty straight forward and in almost every case made our code either more sound or easier to be consumed. Now I work on a runtime that embeds TypeScript and 3.5.1 has broken some code, thought it took me all of about 15 minutes to make the changes to adopt it, and in every case, it broke because we were being a bit loose with the types. While it didn't find any bugs, it made the code more "safe".

Changing every built-in function to accept anys would also "break" no one, but that doesn't make it a good idea. Part of TypeScript's value proposition is to catch errors; failing to catch an error is a reduction in that value and is something we have to weigh carefully against "Well maybe I meant that" cases.

It’s fun but when would we ever use things like this in actual code?When it’s well tested, commented, documented, and becomes an understood idiom of your code base.We focus so much on black magic and avoiding it that we rarely have a chance to enjoy any of the benefits. When used responsibly and when necessary, it gives a lot of power and expressiveness.

In case writing to tmpfile fails for some reason, use && mv ... instead of ; mv ... -- that will keep $file from being overwritten with "bad" content.

The encapsulation is enforced by the language. It is a syntax error to refer to # names from out of scope.

When defining accessors in Ruby, there can be a tension between brevity (which we all love) and best practice.

You can use container values, that wraps actual success or error value into a thin wrapper with utility methods to work with this value. That’s exactly why we have created @dry-python/returns project. So you can make your functions return something meaningful, typed, and safe.

Make your functions return something meaningful, typed, and safe!

You should default to the most permissive option imo and there really is no reason to check anything until you really need to If it were left to me I'd just use optional chaining, as it also eliminates the need for no-ops

Strings generated by devalue can be safely deserialized with eval or new Function

However, IMO, having the conditional in the detach function is necessary, because there are other manifestations of this error. For example, if the DOM element in a component is removed from software outside of svelte, detach will have the same error.

IMO, the conditional needs to be added to detach to fix all manifestations of this error.

detach, as an api, should be declarative (ensure the node is detached) instead of imperative (detach the node), allowing it to be called multiple times by performing a noop if the node is already detached. This way, it won't matter if the node is removed from the DOM from outside of svelte.

For my point of view, and I've been annoyingly consistent in this for as long as people have been asking for this feature or something like it, style encapsulation is one of the core principles of Svelte's component model and this feature fundamentally breaks that. It would be too easy for people to use this feature and it would definitely get abused removing the style safety that Svelte previously provided.