Completion member field listing order w.r.t. C++20 designated initializers

[Falkgaard]

Hi, with the addition of designated initializers with C++20 (https://en.cppreference.com/w/cpp/language/aggregate_initialization) and the limitation that designators for data members need to appear in the same order as they are defined in the struct, it would definitely be nice to have struct fields be listed in the order of definition so that users don't have to jump to the struct's definition (which can be a pain if it's a 15~80K LoC Vulkan-Hpp file, for instance) to check the order every time that they want to use aggregate initialization with designators. Is this possible?

---

Context and Test:

I'm using NeoVim with coc.nvim and coc-clangd, and the "suggest.defaultSortMethod": "none" set in my config (just in case it would default to alphabetical ordering or something), however, when I try to complete a . inside an aggregate initialization brace like this:

struct test {
	int  i;
	bool b;
	char c;
};

int main() {
	test t {
		. // <-- completion here
	};
}

it results in the following completion pop-up listing them in alphabetical order:

b : bool field [LS]
c : char field [LS]
i : int  field [LS] 
b~       field [LS]
c~       field [LS]
i~       field [LS]

instead of the more useful (for C++ designated initialization purposes, at least):

i : int  field [LS] 
b : bool field [LS]
c : char field [LS]
i~       field [LS]
b~       field [LS]
c~       field [LS]

---

If this is already possible, any additional info would be very welcome. And please let me know if this isn't a clangd-specific issue but rather specific to something like coc-clangd and I'll bring it up over there instead.

Keep up the great work!

---

edit:

Maybe this is covered by #306?

[sam-mccall]

Ah, this makes a lot of sense, but it's hard to align with other constraints on ordering:

• it should respond to quality of textual match as you type
• it should be responsive to frequency of use from the index, and other signals like deprecation
• name as tie-breaker does have some readability value and it's applicable in many contexts

And in general our code completion infrastructure isn't equipped to force an order, so this would be a weird special case.

Construction init lists are similar AFAIK (though code completion doesn't work as well there for tedious reasons...)

What do you think about adding/improving fix actions for misordered initializers instead. Would it help much?

[Falkgaard]

Oh, I don't know much about the implementation side of things, but that makes sense. Since the designators always start with a . before the identifier (without a preceding identifiers like when you access member data or member functions) I had assumed that that could be used to list members in the definition order for that specific case since it's always of the structure [implicit type from parameter|explicit type preceding the identifier (if initializing a variable without auto)|explicit type directly preceding the curly brackets] and then just N comma separated .some_field = some_value listings in the curly brackets, so I don't think it would collide with any other cases, but it would definitely be a weird (and potentially) hairy edge case to add.

Your suggestion of using fix actions for it sounds like a great alternative though! I hadn't even considered that approach. I think either approach would solve the issue. :-) Great idea.

[Raildex]

Any news on this?

[MythreyaK]

What do you think about adding/improving fix actions for misordered initializers instead. Would it help much?

PR llvm/llvm-project#173136 should add this.

[HighCommander4]

Let's consider this closed by llvm/llvm-project#173136 -- thanks Mythreya!

The original suggestion (changing the order of completion items) has the challenges discussed in this comment so I'm leaning towards "wontfix" on that one (though I'm open to a concrete proposal that addresses the discussed challenges, which can be made in a separate issue).

Note also the signature help enhancement made in llvm/llvm-project@229c95a which helps this use case (see example in this comment), as well as the idea for a new code completion that inserts all designators with placeholders for their initializers tracked in #2559.