To reply to Adrian telling me why making the value type const lvalue
reference is wrong?
I did a mistake:
I was really sorry for my inconsistent usage of the term const reference
type, what I meant was that it had the semantics of const reference type
(but be a different type) and could decay into one, just like built in
arrays can. This was a stupid mistake that I made because I thought that
it's a small part of the puzzle that might useful to put just to make it
look complete. What I didn't realize was that this will bite me back if not
thought of consciously. I know that you chose capacity for that reason.


***New addition***
The type of the expression of the set and the value selected would be new.
I won't make any assumptions to try to make the puzzle feel complete, and I
am super sorry for doing so.

On Sat, 4 Apr 2026, 12:35 pm Andre Kostur, <andre_at_[hidden]> wrote:

> On Sat, Apr 4, 2026 at 6:53 AM Muneem <itfllow123_at_[hidden]> wrote:
> >
> > Sorry for the late reply( I was showering and using hair oil)
> > Sorry for my confusing reply, really sorry.
> > The short answer is:
> > NO
> > The long answer is:
> > The rules for templates would apply here, and concepts can be used to
> further constraint the requirements and make any resulting errors readable,
> so basically, it would work only if vector and list have the member
> capacity.
>
> That's why I chose capacity(), it doesn't exist in one of the types.
> So you're suggesting that the compile would have to try the syntax
> against every type in the set?
>
> This answer seems inconsistent with one of your previous answers
> regarding the type of 'x': "The answer is the *********const reference
> type********* of the object at the index read' (ignoring the const
> part). If the type of x is std::vector<int>, then there should be no
> reason to fail to compile a call to capacity().
>