[ljm]

I'm reading the comments here about how the languages fails, or what it should have done better, but at the same time I'm feeling the same as I do when building up something with Kubernetes and the problem isn't really the language, it's the shortcuts we take with it to stay concise.

e.g. in Kubernetes you can give a Pod, Deployment, Service, Ingress, Volume, etc. etc. the exact same name and in fact many examples encourage that (because they are namespaced on the type). However this is practically just an artefact of a previous choice and when you're looking at your YAML files you may not immediately know that distinction unless you have some familiarity with the tech.

What it says is that you can call everything the exact same thing. And it will work, and it will seem nice or elegant.

So it is with this Swift example and having a protocol, an extension, and a base class all declaring the exact same thing. Even if the compiler figures it out, how would you without reading the spec or knowing where those files live (because in the real world they would be spread across the filesystem)? It's just poor consideration for comprehension.

[wool_gather]

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?

[xyzzy_plugh]

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.

[wool_gather]

> 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?

[Dylan16807]

> So it is with this Swift example and having a protocol, an extension, and a base class all declaring the exact same thing.

I'm not sure what you mean. The only thing that's named the same is 'greet', and of course that has to be the same because it's the thing you're implementing.

Edit: Perhaps the protocol and extension could have different names? I don't see how that would make the behavior clearer.