No actually, that was the point. I was asking, what do you think should happen if you store a NUL when you're claiming you're not. Or if you don't store a NUL, when you claim it's there.

Well, as a human compiler, I said "Hey, you've non-NUL terminated a NUL terminated string". If that was what you intended you should use the type annotation for that, so I think that case worked as intended.

EDIT: > what do you think should happen if you store a NUL when you're claiming you're not

I don't believe nonstring implies it doesn't end with a NUL, just that it isn't required to.

But char[] already isn't required to be NUL-terminated to begin with. char a[1] = {'a'} is perfectly fine, as is a[0] = '1'. If all you want to do is to document the fact that a type can do exactly what it already can... changing the type to something new doesn't make sense.

Note that "works as intended" isn't sole the criterion for "does it make sense" or "should we do this." You can kill a fly with a cannon too, and it achieves the intended outcome, but that doesn't mean you should.

Is ns NUL terminated, or is it an array of chars that happens to end with NUL?

If ns is __nonstring, it could be the latter. Without it, it should be the former and warn if it's not. That's not ambiguous.