Sorry if I misunderstood the problem.
I am guessing that the use of std::vector::at is out of question in this
case?
The good side of "at" is that it's clear on the contract: Using [] looks
nicer but is unsafe. Using "at" isn't as nice, but is safer.

I am wondering if it is a problem that could be solved through a (strong)
type of indexes:
std::vector::operator[](size_t) -> no bound checking
std::vector::operator[](bound_checked_index) -> bound checking

It would probably make more sense if the strong type of the index brought
other benefits (like std::vector<T>::operator[](bound_checked_index<T>), to
at least guarantee that it's indexing the right type of vector).
I'm mentioning this because I believe that in the general case, stronger
types for vector indexes could avoid errors, even for veteran programmers.

On Sun, 30 Apr 2023 at 15:00, Amir Kirsh via SG20 <sg20_at_[hidden]>
wrote:

> [Sorry, sent with Reply instead of Reply-All. Resending].
>
> The question is, if (when?) these novices get to the industry, wouldn't
> they have a misconception that vector [] checks for out of bounds?
> My view is that since outbounds is the case with C++ (or, as long as it
> is), maybe it is better not to cushion them from the harsh reality, but
> rather make them face it (yes, I understand that it wastes time, that may
> be better spent for other stuff, but then why teach C++ and not Python? If
> they are going to actually work in C++ they should get aware of the way
> it works).
>
> And I say that, while I still believe that "Teaching" shares the letters
> of "Cheating" for a reason.
> It's OK for teachers to cheat a bit, to make things easier for the
> students.
> It's a choice question, when to cheat and when to go with the brutal truth.
> (I also cheat when I teach, but not for vector []. I have my own other
> cheats...).
>
> Regardless of the teaching question, we should think of better approaches
> in the language to avoid this issue (such as compiler profiles for turning
> on bounds checking!), this should be an important drive for the language.
> Something in the direction of Circle's feature directives
> <https://github.com/seanbaxter/circle/blob/master/new-circle/README.md#versioning-with-feature-directives>
> .
> I'm in favor of that!
>
>
> On Sun, Apr 30, 2023 at 4:26 PM Bjarne Stroustrup <bjarne_at_[hidden]>
> wrote:
>
>> Exactly. Thanks. We all (well, several of us) have many different target
>> audiences, but in this particular case, I'm working for rank novices.
>> Independently of that, I think that range checking would be a boon to
>> most users. Only a minority - possibly a large minority - needs that
>> last added performance that you get from not checking. My conclusion is
>> that we need to find ways to serve both groups.
>>
>> For novices, range checking needs to work right out of the box.
>> Installing *anything* is a deterrent.
>>
>>
>> On 4/30/2023 3:11 AM, Ville Voutilainen wrote:
>> > Because that's Bjarne's target audience, students who may not have
>> > programmed before.
>>
> --
> SG20 mailing list
> SG20_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg20
>