An Implementation Model for Rational Protocol Conformance Behavior

[dabrahams (Dave Abrahams)]

@Douglas_Gregor

@dabrahams

Also, true: as the compiler, you do never know whether a conformance is holding up some invariant. I hope we can all agree that upholding invariants is fundamental in supporting the creation of large, reliable systems .

Sure, but since we are bolding things, not every invariant must be handled by the type system .

Wow, when you disconnect that bolded bit from the rest of the paragraph it's almost like you're telling me something I don't know (0.25 x )! Seriously, this is both taking my statements completely out of context and completely missing the point, to wit:

• A language shouldn't create the conditions where the standard manual means of upholding invariants (e.g. documenting stuff, reading the docs, developing best practices, following the implied rules) break down.

I assert that where we've done that, the language needs to change. A secondary point you also missed, was

• It's about what you can easily express unintentionally, not what a type system “handles.”

That's why I mentioned that Python—a language with no static type system—does not create these conditions.

Not the same ballpark as Argument Dependent Lookup, sorry.

Look, I don't want to get into details about C++ here. I'll just say this: when I build the mental “feature comparison chart” for the effects both have on the programming model, their checked rows have significant overlap. I'm not assuming you've dismissed the comparison out of hand, but will encourage you to at least do the same mental exercise if you haven't.

Not everything can be easily separated by files. You can't put the stored properties of a type, or the overridable methods of a class, or the requirements of protocol, into different files. With this rule you propose, users would have to try to defeat the static type checking to get an X , a type from B , and a type from C into the same place. Either they succeed with some contortions (special wrapper types with private fields scattered into different source files, maybe?), in which case the type checking wasn't actually as sound as you want, or they fail and you've prevented a probably-correct program from being written.

OK, fair enough; I don't think the consequences of my rules are as bad as you imply, but TBH we're both guessing, since we don't have any real examples to work with. Suppose we compromise and consider alternative remedies with fewer potential downsides?

Under today's rules, the only possible conformance conflicts in programs that compile are retroactive and all retroactive conformances are public. We should give people a way to opt out of creating conflicts unintentionally, so I propose:

1. We implement scoped conformances.
2. Retroactive conformances become internal by default, after a release in which you're asked to be explicit about whether they're public. A retroactive conformance is defined as one that could conflict under today's model.

These protections would fall on the API vendor side rather than on the client side. I also have ideas for things we can do on the client side that fall well short of “poisoning types,” but let's discuss those separately.

(I'll address the rest of your post, which is important, in a separate message)