Once this lands I'll update the FDE Linux implementation.

QQ about this. Since users can pass an array of type groups in general, and we treat those as an OR (because a wildcard short-circuits the whole thing), why interrupt the processing of type groups because one of them seems wrong?

Shouldn't the check happen at the end, when after looking at all the type groups we cannot find anything compatible with the platform (and the user didn't pass a wildcard?). Additionally we can warn the user that a certain type group will not have any effect on the current platform.

Failing on the first "wrong" group looks like it's breaking the normal short-circuiting of the OR operator. Imagine this:

<FileGroups>[SomeRandomConfig, Wildcard];

Do we want the above to fail (because SomeRandomConfig is not supported in the current platform), or apply a Wildcard? The reverse wouldn't fail, because the Wildcard would supersede the random config (and the user wouldn't be aware of it):

<FileGroups>[Wildcard, SomeRandomConfig];

Since users can pass an array of type groups in general, and we treat those as an OR (because a wildcard short-circuits the whole thing),

This varies by platform, actually. The reason it's an array of groups that are themselves a bunch of arrays, rather than one group, is that on Windows and Linux each group is one entry in a drop-down list in the dialog. So there's no short-circuiting on those platforms; the overall capability of the dialog is an OR, but each group is distinct.

We could be more lenient on some platforms, but my thought was that it's probably not really useful to go out of our way to accept invalid groups in some cases on some platforms. We could also be more strict and always check everything, but that also seemed to me to be more trouble than it's worth; if you think the consistency is important this would be my preference so that we're also consistent with the platforms where we always use everything.

My goal was just to make sure that in any case where we would do the wrong thing we throw instead of silently being wrong, and used the simplest implementation that did that. I agree the behavior varying by order is a bit weird if we compare different invalid cases; how do you feel about validating everything instead of explicitly ignoring invalid groups in cases where they don't actually apply?

Ah, I remember now the Windows and Linux use cases!

it's probably not really useful to go out of our way to accept invalid groups in some cases on some platforms.

Yeah, this is a very good point.

We could also be more strict and always check everything, but that also seemed to me to be more trouble than it's worth;

Haha, nope, I think I prefer having more leniency with the users, rather than being more strict in this :P

in any case where we would do the wrong thing we throw instead of silently being wrong...

I mean, we can be lenient and not completely silent! Something like:

• Parse all the entries
  • If valid (this includes wildcards?): add it to the final list that is going to be passed to the platform.
  • If not valid/noop: during development: warn the user that we've dropped entry X because it doesn't have any of T, U, V properties for the current platform.
• If at the end of all the parsing there's no valid entries: throw ArgumentException, because it seems they tried to configure the groups, but none were valid for the current platform.

In any case, the approach I described above would be as backwards incompatible as the current version, so there's nothing stopping us from changing this to be more lenient (or more strict) down the line; users' code should expect "throwy" methods from this point on.

Also, I suspect people are creating XFileGroups statically somewhere and hiding them from sight, so it's likely that once they get it right it never gets touched again (or only when they want to support a new platform!)

Let's land this one!