You make a fair point, but isn't it part of a platform's responsibility to not make footguns quite so easy to grab? Especially given Swift's general (and mostly helpful) attitude of insistence on safe, explicit constructs. For example, it's a warning to ignore a function call result; it's an error to not chain up to a superclass's initializer; it's an error to re-implement a class member without the `override` keyword.
Doesn't this situation deserve similar compiler scrutiny?
The problem with this angle is that while sure, you can always make a compiler more intelligent in ambiguous situations, you must also now train all the humans interfacing with it to be equally as intelligent (or at least, able to sufficiently disambiguate).
We don't see many context-sensitive grammars for programming languages, not because very difficult to implement, but I suspect because they're hard for humans to understand.
There is something to be said for the simplicity of naming things to describe what they are (e.g. Hungarian notation), but I really think it's a mistake for languages (configuration, programming, etc.) to even allow identifiers to be reused for differing types.
> make a compiler more intelligent in ambiguous situations, [but] you must also now train all the humans interfacing with it to be equally as intelligent
I'm not sure what you mean here; probably I'm misunderstanding you somehow.
If you make the compiler more intelligent so that it can tell the humans about subtle problems, that lets the humans be less intelligent (or at least have to think less). No?
Doesn't this situation deserve similar compiler scrutiny?