[augmentations] Making the order of part directives be semantically significant

[bwilkerson]

The proposal for augmentations reads

In some cases (enum values, with clauses, etc.), the order that augmentations are applied is user-visible, so must be specified.

It then goes on to specify a fairly complex, though reasonably intuitive set of rules for deciding the order. One of those rules makes the order of part directives significant.

I don't know whether there's any better way to specify the order, but I do wonder how this will impact agents. If agents don't understand the implications of the ordering (and it seems likely that they won't when the feature is first released) they might attempt to sort the directives.

That observation led me to wonder whether there might be a way to catch when the semantics aren't right because of them being re-ordered. I don't have any ideas at this point, but one possibility that occurred to me is to make the ordering more explicit in the code in the first place so that the order of the directives isn't the deciding factor.

This issue is to see whether the language team has considered this issue and what thoughts you might have.

[lrhn]

99% of the time, the ordering of augmentations are not important.
The two cases where they are:

• Enum elements added by two different fragments.
• Mixin applications added by two different fragments.

In those cases, it still only matters if:

• The index value of the enum values are used, or the order of the values list matters. (Just using enums with == or switches does not care about order).
• The mixin applications invoke members declared implemented by each other.

In both of these cases, if the order matters then there declartions are not probably not unrelated, and therefore it's less likely that they're introduced in completely unrelated declarations. I'd expect the declarations to be located in related locations, either the same file, or one below the other.

The other problem is much more fail-fast: If you move the introductory declaration to after an augmenting declaration, then it's a compile-time error. It has no semantic meaning, the augment keywords are entirely sanity-checking. All errors related to them are "you must write augment here" or "you must not write augment here". A quick "fix augment keywords" is enough to solve that.
I'm sure an AI can be taught to run such a quick-fix if it gets any "augment keyword error".

I can see how an AI might not think that ordering matters (or maybe we can teach it, when it has some tree-structured libraries to look at), and may not care where it adds an augmenting declaration.
But an AI can just modify the original declaration directly, it doesn't need to introduce augmentations at all. I don't think it will.
The biggest risk of confusion would come from the human author having augmentations in different places, and an AI deciding to update one of them, with no good reason to choose one over another. (Because it doesn't understand the reasoning for the separation, and it's already learnged that in most cases order doesn't matter.)

Or that the augmentations come from code generation, and the AI doesn't recognize that, and tries to modify them.
That's a general problem, not just for augmentations.

Apart from AI agents, humans can also reorder (or sort) their part directives.
That can change the same orders. Again, if the order really matters and was introduced deliberately, I'll expect the files or declarations to be ordered above/below each other, and then reordering inside a single file won't change anything.
(And if ordering is deliberate and matters, then tests should be checking it.)

It still leaves reordering of enum elements that you don't care about, but your library's clients have depended on it in some way ("Putting all the failure codes at the end was not deliberate?!?").

Maybe it would be worth adding logic to part-directive reorderings that tell you if something changed semantically.
Say "You just sorted part directives, and this changed the element order of enum Foo. Did you mean that (Y/N)?".

All in all, I think ordering will matter practically never, and when it does, it's so deliberate that the related declarations will have related positions too.