> "associated contractual precondition"
>
> Contracts are defined for functions, not for built-in operations.
> If you want to extend the concept, it might be better to
> avoid the word "contract" and "precondition" and just
> state the conditions and the effects when violated.

You are right that I shortcutted explanation, but in essence I would see
that provenance checking would be implemented very similarly to contract
checking i.e. optional runtime checking.

I will add a clarifying footnote.

> 4.6.1
> "non-void, non-null, non-function pointer object"
>
> This mixes value with type and has a lot of "non".
> Also, is this intended to cover only pointer objects
> (i.e. pointers that are materialized somewhere in memory)
> or also pointer values (which might live in a register)?
> I think this wants to talk about both.

I wasn't aware there is a difference between pointer objects and pointer
values. I had assumed (I am guessing incorrectly) that pointer objects
are trivially copyable and thus can be stored in registers.

> Suggestion: "non-null pointer to object"

I was trying to avoid using that phrase :). I am hoping to leave open
the door to Modules, and functions, becoming objects in the future.

Equally, if it's a problem to consider that right now, it can be axed.

> Where did "safely-derived pointer value" go? The section
> was replaced entirely, it seems.

It was for this draft. This is because I do not fully understand how
P1434 could work in practice. I have received further notes from its
authors, and will try to do better in a future draft.

> "The following operations involving two non-void, non-null pointers shall fail to compile with a
> diagnostic:
> Comparisons, including equality and inequality, of two pointers without common provenance
> (user should convert to void* beforehand)."
>
> It seems "provenance" of a pointer is a runtime property, so how can
> that cause a compile-time diagnostic?

Under P1434, provenance is wholly a runtime property.

Under my proposal, I have rather fudged the situation by envisaging a
mixed runtime and compile-time checked property. If the compiler can
statically prove that provenance can never be common, it must error out.
At least, this is what I was trying to state.

Here's an example:

T a[5], b[5];
if(a == b) ...

Right now the compiler can at compile time infer this condition must
always be false. Under my proposal, it would fail to compile. Under
P1434, it would fail during execution.

Niall