3 ms·

I'm going to dodge the breaking changes discussion, since it's a huge tangent, suffice to say that I greatly dislike _breaking_ changes and want languages that

I'm going to dodge the breaking changes discussion, since it's a huge tangent, suffice to say that I greatly dislike _breaking_ changes and want languages that make it possible to avoid them or at least provide a migration path via incremental deprecation prior to removal. Go fails here in many ways. All I meant to do was point out that exhaustiveness checks are not without their tradeoffs. > I was visualising something like OK then. We're in agreement on that point. This is what Clojure has in it's destructuring syntax, and, as I said, it's great.

dbaupp 10y ago
> All I meant to do was point out that exhaustiveness checks are not without their tradeoffs. And all I meant to do was point out that lack of exhaustiveness checks is not without its tradeoffs. :)
codygman 10y ago
> I'm going to dodge the breaking changes discussion, since it's a huge tangent, How is it a tangent? One of the biggest reasons to want exhaustiveness checking is to avoid the even uglier problem of "compiling but semantic changing" changes. > I greatly dislike _breaking_ changes and want languages that make it possible to avoid them It seems you are only talking about disliking breaking changes that cause your program not to compile whole totally disregarding the danger of changes that compile but change semantics. As respectfully as possible, that seems backwards to me.