Alternative to @target

[GearsDatapacks]

The @target attribute is deprecated and should not be used, however there is currently no alternative in many situations. We want to have a better feature to replace it in future, but a concrete design has yet to be proposed. I would like to create this discussion as an opportunity to discuss possible designs for features to replace @target.

I know the basics of what we want for this feature, but please suggest other requirements to add.

What we want

1. The ability to run different code on different targets, with both implementations being in pure Gleam. For example, a particular operation might be more efficient on Erlang than JavaScript, and you want to take advantage of that.

2. Different implementations per target to both be considered during semantic analysis, so problems like unused imports or functions on a particular target do not occur. This should also apply to documentation generation, as that is another common problem with @target.

What we don't want

1. The ability to completely erase functions when compiling to a particular target. This leads to bad semantic analysis and poor error messages.

2. The ability to change the API (type signature or labels) of a function or constant based on the target.

3. The ability to modify a type definition or type alias based on the target.

Other considerations

1. We might also want the ability to conditionally compile functions per target. This doesn't hide them from semantic analysis, only prevents code generation. For example, you might want to write a test that only applies to a specific target, like testing that a particular function does not cause a stack overflow on the JavaScript target.

2. The limitation that packages must provide full support for one target (and partial support for the other) has been raised as a potential issue with new features. This may need to be reconsidered.

This may end up needing to be multiple different features which cover different parts of @target's previous uses.

[lpil]

Thanks for making a discussion! I've got some R&D done in this area but haven't shared anything publicly yet.

The ability to define different values of a constant on different targets. For example, a const target: String which tells you which target you are running on.

What're the motivating use cases for this one? It's listed as a concrete requirement but it's not something I've seen a need for in real code yet.

This may end up needing to be multiple different features which cover different parts of @target's previous uses.

This is my expectation, yes.

Potential additional requirements

Today a package must have full support for at least 1 target (the one they use when they run the build tool) and partial support for the other (which they would not be able to run the build tool for).

This has two consequences that I can see:

1. The programmer is unable to run the tests the target with only partial support.
2. The programmer is unable to provide specialised APIs for both targets.

Consequence 1 seems unambiguously a problem.

Consequence 2 seems like it would typically not be an issue, but for some packages it would become a major problem, forcing them to offer sub-standard API for specific targets (e.g. Lustre not having a OTP compatible API for server components, which would really be need in a production application) and possibly to have "dud" implementations for one target for certain functions.

[GearsDatapacks]

What're the motivating use cases for this one? It's listed as a concrete requirement but it's not something I've seen a need for in real code yet.

Yes, perhaps this is not something we want. I haven't really used @target all that much so this was mostly an extension of the different function behaviour per target. I can remove that one.

Today a package must have full support for at least 1 target

As mentioned in #5193, I believe this should maybe be revisited, especially if introduction of new features makes this limitation even more of a problem.