> I'm going to need you to walk me so I can see how that part you quoted implies that the code being correct doesn't matter.
Well, that quote was your entire sentence. It wasn't out of context. So:
> every time the code changes, it would be great if a test somewhere broke
There isn't anything anywhere about the code being incorrect. Thus it is irrelevant.
About the types, their entire point is that they save you from writing the tests. What the compiler proves, you do not test. If your compiler won't prove anything, you'll have to write all the tests.
As an example, you forgot to test if `'nos': ("", None)` yields the correct error.
> As an example, you forgot to test if `'nos': ("", None)` yields the correct error.
It isn't in the go code either.
> There isn't anything anywhere about the code being incorrect. Thus it is irrelevant.
Why, exactly? I'm not following your inference there; again, walk me through that one.
Let me be more explicit: what exactly did you think I meant with that line? Again, I don't see how it implies that "it doesn't matter whether the code is correct".
> About the types, their entire point is that they save you from writing the tests.
Ok, this is getting circular so I'll just ask you to give me an example of a test that would be absolutely required in a dynamic language but not in a static one.
Mind you, that isn't going to convince me one way or another in the "static vs dynamic" flamewar since I subscribe to the idea that more tests is better. I'm asking mostly out of curiosity.
Well, that quote was your entire sentence. It wasn't out of context. So:
> every time the code changes, it would be great if a test somewhere broke
There isn't anything anywhere about the code being incorrect. Thus it is irrelevant.
About the types, their entire point is that they save you from writing the tests. What the compiler proves, you do not test. If your compiler won't prove anything, you'll have to write all the tests.
As an example, you forgot to test if `'nos': ("", None)` yields the correct error.