Date: Sat, 4 Apr 2026 09:31:02 +0500
Hi!
Mr.Andre kustor asked a very good and welcomed question:
If I were to write:
auto & x =
return_index_chosen(read_from_string<uint8_t>(string_to_read_from,
pos));
What is the type of x ? Particularly if string_to_read_from is a runtime
value.
The answer is the *********const reference type********* of the object at
the index read by "read_from_string<uint8_t>(string_to_read_from,
pos)" that of course can be modified after type casting const_cast. if the
"const" is an issue then please propose something else, I really need to
see if it's not perfect.
*********Mistake in previous example*********
The previous example that I passed didn't have const cast expression, but I
still modified the value returned by at(), which was a mistake. So I am
really sorry for that.
*********Mistake in previous example*********
*********Discussion(skip if you arent Interested in to the long
answer)*********
Basically using auto & x =
return_index_chosen(read_from_string<uint8_t>(string_to_read_from,
pos)); instead of the switch statements, you give me compiler a free hand
to make the *********intermediate code representation(llvm code)*********
to be what ever is the most efficient. This is why I am pushing for this
construct:
It's not verbose and efficient to deal with before any compiler backend
run(for example: llvm)
*********Discussion*********
On Sat, 4 Apr 2026, 9:21 am Muneem, <itfllow123_at_[hidden]> wrote:
> Hi!
> Mr.Andre kustor asked a very good and welcomed question:
> If I were to write:
>
> auto & x =
> return_index_chosen(read_from_string<uint8_t>(string_to_read_from,
> pos));
>
> What is the type of x ? Particularly if string_to_read_from is a runtime
> value.
>
> The answer is the *********const reference type********* of the object at
> the index read by "read_from_string<uint8_t>(string_to_read_from,
> pos)" that of course can be modified after type casting const_cast. if the
> "const" is an issue then please propose something else, I really need to
> see if it's not perfect.
>
> *********Discussion(skip if you arent Interested in to the long
> answer)*********
>
> Basically using auto & x =
> return_index_chosen(read_from_string<uint8_t>(string_to_read_from,
> pos)); instead of the switch statements, you give me compiler a free hand
> to make the *********intermediate code representation(llvm code)*********
> to be what ever is the most efficient. This is why I am pushing for this
> construct:
> It's not verbose and efficient to deal with before any compiler backend
> run(for example: llvm)
>
> *********Discussion*********
>
> On Sat, 4 Apr 2026, 9:13 am Andre Kostur, <andre_at_[hidden]> wrote:
>
>> On Sat, Apr 4, 2026 at 3:33 AM Muneem via Std-Proposals
>> <std-proposals_at_[hidden]> wrote:
>> >
>> > I am really really sorry for the gap in communication that we all had,
>> like our cultures defer, unfortunately, so I can't really understand how to
>> phrase things properly (sadly). Thank you to both Mr. Jason and Mr. Steven
>> for their guidance and support.
>> >
>> > First let me (as Steven told me to provide a simple aspect of this
>> feature) before moving on to the actual code(discussion section):
>> > *********This is the problem*********
>> > Try reading input from the user to push, pop, insert, push into the
>> element type, etc, to any of this types show in less than a thousand lines:
>> > namespace type_information_storage_facilities{
>> > std::vector<Type_info_t>
>> vector_containing_type_collections;
>> > std::deque<Type_info_t>
>> deque_containing_type_collections;
>> > std::vector<Type_info_t>
>> map_containing_type_collections;
>> > std::vector<Type_info_t>
>> hash_map_containing_type_collections;
>> > std::list<Type_info_t>
>> list_containing_type_collections;
>> > std::forward_list<Type_info_t>
>> forward_list_containing_type_collections;
>> > }
>>
>> Ahem: there's 3 vectors in there, are two of those supposed to be
>> std::map and std::unordered_map ?
>>
>> > Basically trying to decide between the advantages of each
>> container's(or any group of objects) space and time gurrentied at runtime.
>> >
>> > *********This is the problem*********
>> >
>> > *********The proposed syntax*********
>> > /*The defintion of all those containers and enums are here in a proper
>> namespace hierarchy*/
>> > //Forgive me if the style of my code is unorthodox:
>> > (Syntax from my proposal from GitHub):
>> > {vector_containing_type_collections, deque_containing_type_collections,
>> map_containing_type_collections,
>> > hash_map_containing_type_collections,
>> > list_containing_type_collections,
>> > forward_list_containing_type_collections}
>> > return_index_chosen(any integer that ful fills the is integral concept
>> index);
>> > //In short indexed using return_index_chosen(int), but the (proper)
>> example is below:
>> > inline void change_collection_of_types
>> > (const std::string&
>> string_to_read_from, std::string::size_type* pos){
>> > auto type_info=
>> get_collections_of_types_from_string(string_to_read_from, pos);
>> >
>> >
>> >
>> > //*********Expression where my proposed syntax is used*********:
>>
>> return_index_chosen(read_from_string<uint8_t>(string_to_read_from,
>> pos)).at(read_from_string<Get_cont_size_type_t<decltype(array_containing_types))>>(string_to_read_from,
>> pos))= std::move(type_info);
>> > }
>> >
>> > //The diffiency is the syntax currently used by my code
>> > *********The proposed syntax*********
>>
>> Stop here. If I were to write:
>>
>> auto & x =
>> return_index_chosen(read_from_string<uint8_t>(string_to_read_from,
>> pos));
>>
>> What is the type of x ? Particularly if string_to_read_from is a runtime
>> value.
>>
>
Mr.Andre kustor asked a very good and welcomed question:
If I were to write:
auto & x =
return_index_chosen(read_from_string<uint8_t>(string_to_read_from,
pos));
What is the type of x ? Particularly if string_to_read_from is a runtime
value.
The answer is the *********const reference type********* of the object at
the index read by "read_from_string<uint8_t>(string_to_read_from,
pos)" that of course can be modified after type casting const_cast. if the
"const" is an issue then please propose something else, I really need to
see if it's not perfect.
*********Mistake in previous example*********
The previous example that I passed didn't have const cast expression, but I
still modified the value returned by at(), which was a mistake. So I am
really sorry for that.
*********Mistake in previous example*********
*********Discussion(skip if you arent Interested in to the long
answer)*********
Basically using auto & x =
return_index_chosen(read_from_string<uint8_t>(string_to_read_from,
pos)); instead of the switch statements, you give me compiler a free hand
to make the *********intermediate code representation(llvm code)*********
to be what ever is the most efficient. This is why I am pushing for this
construct:
It's not verbose and efficient to deal with before any compiler backend
run(for example: llvm)
*********Discussion*********
On Sat, 4 Apr 2026, 9:21 am Muneem, <itfllow123_at_[hidden]> wrote:
> Hi!
> Mr.Andre kustor asked a very good and welcomed question:
> If I were to write:
>
> auto & x =
> return_index_chosen(read_from_string<uint8_t>(string_to_read_from,
> pos));
>
> What is the type of x ? Particularly if string_to_read_from is a runtime
> value.
>
> The answer is the *********const reference type********* of the object at
> the index read by "read_from_string<uint8_t>(string_to_read_from,
> pos)" that of course can be modified after type casting const_cast. if the
> "const" is an issue then please propose something else, I really need to
> see if it's not perfect.
>
> *********Discussion(skip if you arent Interested in to the long
> answer)*********
>
> Basically using auto & x =
> return_index_chosen(read_from_string<uint8_t>(string_to_read_from,
> pos)); instead of the switch statements, you give me compiler a free hand
> to make the *********intermediate code representation(llvm code)*********
> to be what ever is the most efficient. This is why I am pushing for this
> construct:
> It's not verbose and efficient to deal with before any compiler backend
> run(for example: llvm)
>
> *********Discussion*********
>
> On Sat, 4 Apr 2026, 9:13 am Andre Kostur, <andre_at_[hidden]> wrote:
>
>> On Sat, Apr 4, 2026 at 3:33 AM Muneem via Std-Proposals
>> <std-proposals_at_[hidden]> wrote:
>> >
>> > I am really really sorry for the gap in communication that we all had,
>> like our cultures defer, unfortunately, so I can't really understand how to
>> phrase things properly (sadly). Thank you to both Mr. Jason and Mr. Steven
>> for their guidance and support.
>> >
>> > First let me (as Steven told me to provide a simple aspect of this
>> feature) before moving on to the actual code(discussion section):
>> > *********This is the problem*********
>> > Try reading input from the user to push, pop, insert, push into the
>> element type, etc, to any of this types show in less than a thousand lines:
>> > namespace type_information_storage_facilities{
>> > std::vector<Type_info_t>
>> vector_containing_type_collections;
>> > std::deque<Type_info_t>
>> deque_containing_type_collections;
>> > std::vector<Type_info_t>
>> map_containing_type_collections;
>> > std::vector<Type_info_t>
>> hash_map_containing_type_collections;
>> > std::list<Type_info_t>
>> list_containing_type_collections;
>> > std::forward_list<Type_info_t>
>> forward_list_containing_type_collections;
>> > }
>>
>> Ahem: there's 3 vectors in there, are two of those supposed to be
>> std::map and std::unordered_map ?
>>
>> > Basically trying to decide between the advantages of each
>> container's(or any group of objects) space and time gurrentied at runtime.
>> >
>> > *********This is the problem*********
>> >
>> > *********The proposed syntax*********
>> > /*The defintion of all those containers and enums are here in a proper
>> namespace hierarchy*/
>> > //Forgive me if the style of my code is unorthodox:
>> > (Syntax from my proposal from GitHub):
>> > {vector_containing_type_collections, deque_containing_type_collections,
>> map_containing_type_collections,
>> > hash_map_containing_type_collections,
>> > list_containing_type_collections,
>> > forward_list_containing_type_collections}
>> > return_index_chosen(any integer that ful fills the is integral concept
>> index);
>> > //In short indexed using return_index_chosen(int), but the (proper)
>> example is below:
>> > inline void change_collection_of_types
>> > (const std::string&
>> string_to_read_from, std::string::size_type* pos){
>> > auto type_info=
>> get_collections_of_types_from_string(string_to_read_from, pos);
>> >
>> >
>> >
>> > //*********Expression where my proposed syntax is used*********:
>>
>> return_index_chosen(read_from_string<uint8_t>(string_to_read_from,
>> pos)).at(read_from_string<Get_cont_size_type_t<decltype(array_containing_types))>>(string_to_read_from,
>> pos))= std::move(type_info);
>> > }
>> >
>> > //The diffiency is the syntax currently used by my code
>> > *********The proposed syntax*********
>>
>> Stop here. If I were to write:
>>
>> auto & x =
>> return_index_chosen(read_from_string<uint8_t>(string_to_read_from,
>> pos));
>>
>> What is the type of x ? Particularly if string_to_read_from is a runtime
>> value.
>>
>
Received on 2026-04-04 04:31:16
