The C pointer provenance is still in TS form and is largely constructed by trying to retroactively justify the semantics of existing compilers (which all follow some form of pointer provenance, just not necessarily coherently). This is still an area where we have a decent idea of what we want the semantics to be but it's challenging to come up with a working formalization.

I'd have to double-check, but my recollection is that the current TS doesn't actually require that you be able to implement user-written memcpy, rather it's just something that the authors threw their hands up and said "we hope compilers support this, but we can't specify how." In that sense, byte type is going beyond what C does.

> The C pointer provenance is still in TS form and is largely constructed by trying to retroactively justify the semantics of existing compilers

That's my understanding too

> I'd have to double-check, but my recollection is that the current TS doesn't actually require that you be able to implement user-written memcpy, rather it's just something that the authors threw their hands up and said "we hope compilers support this, but we can't specify how."

That's also my understanding

> In that sense, byte type is going beyond what C does.

I disagree, but only because I probably define "C" differently than you.

"C", to me, isn't what the spec describes. If you define "C" as what the spec describes, then almost zero C programs are "C". (Source: in the process of making Fil-C, I experimented with various points on the spectrum here and have high confidence that to compile any real C program you need to go far beyond what the spec promises.)

To me, when we say "C", we are really talking about:

- What real C programs expect to happen.

- What real C compilers (like LLVM) make happen.

In that sense, the byte type is a case of LLVM hardening the guarantee that it already makes to real C programs.

So, LLVM having a byte type is a necessary component of LLVM supporting C-as-everyone-practically-it.

Also, I would guess that we wouldn't be talking about the byte type if it wasn't for C. Type safe languages with well-defined semantics have no need for allowing the user to write a byte-copy loop that does the right thing if it copies data of arbitrary type

(Please correct me if I'm wrong, this is fun)

bytewise copy just works with the TS. What it does not support is tracking provenance across the copy and doing optimization based on this. What we hope is that compilers drop these optimizations, because they are unsound.