Yes, you could, but not verifying input usually isn't advisable. It's making a closed-world assumption that isn't warranted in an environment where there are no guarantees. Networks are all about sharing data with other organizations. Filesystems contain files with uncertain origins.

A type system should be designed based on what invariants you can reasonably expect in the environment where the system operates, versus what you can expect will change. For example, Swift has an interesting type system that's specifically designed to make upgrading dynamic libraries easier and safer. Apple can make assumptions about what sort of changes there will and won't be to the libraries that ship with its operating systems.

Contrast with Go, which makes the assumption is that there are no dynamic libraries; all Go source code is seen by the compiler.

> Yes, you could, but not verifying input usually isn't advisable.

It's not not verifying input. It's just not verifying the types. There are no additional security issues unless you do something spectacularly stupid.

For example you can load random bytes as a Protobuf file. It never validates that the data is in fact the right type, it just loads the bytes assuming they are. The only issue you'll see is junk data (or a parse error).

In any case I think you know that. I'm not really sure what point you were trying to make.

I'm not that clear about what point you're making either. We seem to talking past each other?

The way I see it, types are sometimes used to represent security guarantees, so junk data getting cast to the wrong type could be a security hole. It depends on which types we're talking about.

For example, you can declare a SafeHTML type whose underlying representation is a string, and if you somehow deserialize it without actually doing the runtime check, it could be a security bug.

Verifying types and verifying input are closely related; the type keeps track of what you verified when you constructed an object of that type.