Make augment import syntax be `augment import`.

[lrhn]

The current syntax for importing augmentation libraries is import augment <uri>.

That's currently unambiguous, but would not be so if we introduce import shorthand without quotes, like #649.

I suggest changing it to augment import, which is not unambiguous itself because import is only a built-in identifier.
If we make augment a built-in identifier too, in all libraries, it will be unambiguous, needing no lookahead, since built-in identifiers cannot be parsed as a type.

[jakemac53]

If we are going to make that change, should we just make it augment <uri>? I think the only reason to not do that was to make things unambiguous without making augment a built-in identifier in all libraries.

[lrhn]

Sure, augment alone should be sufficient, and even better without the confusing mix of import and something which is not a separate library.
I'm not terribly worried about introducing built-in identifiers.

I still want to remove the distinction between parts and augments, but that's for another day.

Consider whether to allow augment <configurableUri>. It may just be "no", we don't allow it for parts either.

[jakemac53]

Consider whether to allow augment <configurableUri>. It may just be "no", we don't allow it for parts either.

I actually do think we should support this, I think if you look for instance at the current issues surrounding the Int64 effort, configurable augmentations would provide a much more coherent story.

Really any time you want a platform specific implementation of a type, they allow you to do it without introducing an interface and N different implementations.

[lrhn]

You don't need an interface, just n different implementations. The interface is there only to share documentation, or a shared base class to share parts of the implantation.

The problem with configurable parts is that the part points back to the library, with the assumption that the part will then be included by the library.
Looking at a part file, you still can't analyze it by starting at the library file, if the part isn't actually included into the library.

Libraries are self-contained, so they can be analyzed even if they are not imported.
Except if they rely on a cyclic dependency with the conditionally importing library.

(The solution to that is to move the interface into a separate library, which the conditionally imported library imports, and that the conditionally exporting library exports, so there is no direct dependency on the conditionally exporting library.)

Augment parts are not self-contained, they depend on the declarations that they augment, so the same part-of issues apply to them, and it may not be a good idea to allow them to be configurable.

[jakemac53]

You don't need an interface, just n different implementations. The interface is there only to share documentation, or a shared base class to share posts of the implantation.

In the Int64 case it also should solve the analysis problem (which sure, could be solved in other ways, but they are expensive for the user and complicated for us).

The problem with configurable parts is that the part points back to the library, with the assumption that the part will then be included by the library.
Looking at a part file, you still can't analyze it by starting at the library file, if the part isn't actually included into the library.

I see what you mean here, cc @scheglov thoughts? The analyzer could basically end up having multiple versions of the same library in the same context, if you had configurable augmentation imports.

Libraries are self-contained, so they can be analyzed even if they are not imported.
Except if they rely on a cyclic dependency with the conditionally importing library.

The cyclic dependency case does lead to exactly the same problem though.

(The solution to that is to move the interface into a separate library, which the conditionally imported library imports, and that the conditionally exporting library exports, so there is no direct dependency on the conditionally exporting library.)

I agree that can fix the problem but it is a more complicated solution which would be a lot more directly solved by just having platform specific augmentations fill in the platform specific bits of the class directly.

Augment parts are not self-contained, they depend on the declarations that they augment, so the same part-of issues apply to them, and it may not be a good idea to allow them to be configurable.

This seems like an analyzer specific problem (since it is the only tool that would start from an augmentation import, and not the main library).

[scheglov]

The analyzer could basically end up having multiple versions of the same library in the same context, if you had configurable augmentation imports.

We will not analyze an augmentation that is not included into a library. At least it will not be an augmentation of a library, instead currently we recover by analyzing such "orphan" parts and augmentations as their own libraries. Which probably leads to many compile-time errors in them, but at least allows some semantic services, like completion. Theoretically we could branch libraries by configurations, but it would be expensive to implement.

[jakemac53]

We will not analyze an augmentation that is not included into a library.

Long term we do probably want some sort of solution to ensure all of them are analyzed (and in the right context) but this seems like a reasonable enough solution to start with to me.

[davidmorgan]

Closing in favour of the planned switch to part files #3848