Describing the containers in this way, is high-level and low-level at the same time. I would start such an endeavour by creating the description of new (possibly similar) containers, not existing ones from the standard library. Than you are more flexible to change their interface and guarantees to fit the proposal. Only as soon as that gives a good result usable by the compiler, one can think about transferring those results to the existing standard library and third-party tools.   -----Ursprüngliche Nachricht----- Von:Ehsan Amiri via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Mo 13.01.2025 22:48 Betreff:Re: [std-proposals] Providing information about data structures to the compiler An:std-proposals_at_[hidden]; CC:Ehsan Amiri <ehsan.amiri_at_[hidden]>; Thanks for the good points you brought up. The intention here is to help prove legality of compiler optimizations. I think we need to focus on common cases. Most important things in my opinion are the following (in the order of importance): 1-A definition of a “container” in a way that can provide guarantees about the underlying memory allocated for the container and who can access it. (To help with alias analysis) 2-Specifying basic operations such as add/remove/alloc/realloc/dealloc/size. 3-Possibly specifying the type of container could help as well (vector, priority queue, etc.). This can provide extra guarantees about the behavior of the code and we have optimizations that can take advantage of this. You correctly mentioned: “the list of possibilities is endless”. I agree. The more specialized attributes, are less likely to appear in the code and less likely to be useful for the compiler. So we have to stop somewhere. I hope this can address your concerns.