Introducing role keywords to reduce hard-to-find bugs

[Paul_Cantrell]

Thanks for these thoughts, Dave. It’s a vexing problem. Quoting this especially for its insight:

@dabrahams

Even if you discard all the language mechanisms that can get the program into trouble, the basic issue still exists: two independently-developed components can use the same or similar names with very different meanings. The computer can handle it, but it’s still a problem for humans. So at its root, this is an artifact of having a library ecosystem.

As I mull all this over, I keep coming back to this:

@Paul_Cantrell

Is there a way of using it to give method implementations a uniform meaning to the developer, regardless of whether they are nested in a class, a struct, an extension, or (pending inline default impls) in a protocol?

That’s the crux of it for me. If we could answer “yes,” I would be a happy redhead.

(By “uniform meaning” I just mean the developer should be able to reason correctly about the answers to semantic distinctness questions: Does this method implementation newly introduce a semantically distinct behavior? Does it override an existing one? Could it be overridden?)

We aren’t ever going to make semantic distinctness questions painless, but it feels like we should be able to at least make them orthogonal to the rest of the language. More orthogonal than they are, anyway. The “Ghost of Swift Bugs Future” status quo centers around the fact that rules about semantic distinctness of a thing currently depend on what it’s nested inside in ways that seem unnecessary.

[felix91gr (Félix Fischer)]

I'm late to comment on your idea, but regardless: I like it, specially in how it brings much more structure to the protocols' usage.

Atm they have too many degrees of freedom. We're probably better off with a more strict/regular protocol usage.

[hlovatt (Howard Lovatt)]

Thanks