On Fri, Aug 29, 2025 at 04:16:36PM -0700, Oliver Hunt wrote:
>
>
> > On Aug 29, 2025, at 2:43 PM, Levo D via Std-Proposals <std-proposals_at_[hidden]> wrote:
> >
> > The goal of my proposal is to have all bounds be checked at compile time. If I were including containers, the check would be for all containers (and arrays).
> > I haven't seen "hardened preconditions," but glancing at P3471R0, it looks like it's a runtime check, which isn't my goal.
>
> If the bounds and index are known constants at runtime the will be removed. If the bounds and/or index are not known/guaranteed the check _must_ be at runtime. That’s fundamentally unavoidable.
>
> > There isn't anything I could add to that. It'd be helpful if that proposal went through, since there might be a lot of changes inside a code base for access to be provably in bounds.
> > Off the top of my head, there might not be too many changes in my current one and one for containers.
>
> It sounds like what you want is a _dianostic_ for trivial cases, which is already present in clang (it’s a warning by default, but you can turn it into an error with -Werror=array-bounds).
>
> Slices as you’re proposing aren’t like to happen because the path to memory safety requires moving away from C arrays and pointers as they simply do not have bounds information, and in most cases the information available can't be relied on - this is why despite their best efforts -fbounds-safety can easily require quite a lot of annotations.
>
> The correct thing to do is use things like std::span and similar.

The proposal has code that gcc will compile that goes out of range with a literal with no warning.
Some people don't use std (embedded and games), so I would rather have array support so they have some safety
The proposal has text on how to check if a runtime variable is always in range at compile time (using control flow)

 
> > The harder part is stating when a container shouldn't have a bounds check (unless I should explicitly name all the containers that should have it).
>
> No - if you know the bounds of an object it is _always_ broken to access out of the bounds.

There's code showing that compilers will allow it, even when it's a literal and size is known.
 
> > A map where people may want mapVar[-123] to return a value shouldn't be checked,
>
> I’m not sure what you mean? Do you mean std::map<int, ..> or similar? There would not be a bounds check for that: it’s a map, not an array?

Maybe the correct solution is an attribute, which isn't automatic. I was talking about what if the proposal was for containers, and if there was an automatic way to apply checking, but now I think that's likely the wrong move.
I agree that it doesn't make sense for map to be bounds checked. If I had sat on the email, I would have known it'd be a distraction to the conversation.
An attribute that users can throw onto their own containers is probably the right move.

 
> > although I'm unsure if people want me to include a case for maps where we need to check if a key exists before using it that way.
>
> It is indeed somewhat annoying that operator[] does not really have a good way to distinguish reading vs writing, so your choice is implicit creation of an entry that may not be written to (resulting a key being present but not written, etc), a fairly exciting proxy, or triggering some kind of error.
>
> But this is not bounds checking - the range of the key is not relevant.
>
> —Oliver
>
> > --
> > Std-Proposals mailing list
> > Std-Proposals_at_[hidden]
> > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>