Gate future features behind an @@experimental directive.

[cristianoc]

Sometimes features in the compiler are ready ahead of time, but for some reason they belong to the next version of the compiler.
Instead of letting them leave in some branch, that needs rebasing and maintenance, they can be gated under an @@future directive.
The idea is that

@@future

...

will enable all the future features.

And one can select individual one using @@future(feat1, feat2)

[cristianoc]

Here's a test of how easily one can pick up the meaning of this as well as the %ffi directive with no previous context.

Interactive session with gpt3.5.

What does this ReScript code do?

@@future(uncurriedByDefault, ffiArityCheck)

let sum : (int, int) => int = %ffi(function(x,y) { return x+y; })

This ReScript code defines a function called sum that takes two integers as arguments and returns an integer. The function is implemented using a foreign function interface (FFI) to call a JavaScript function that performs the addition.

Here's a breakdown of the code:

• @@future(uncurriedByDefault, ffiArityCheck): This is a compiler directive that sets some options for the future feature of ReScript. The uncurriedByDefault option indicates that uncurried functions should be used by default, and ffiArityCheck enables arity checking for FFI functions.

• let sum : (int, int) => int = %ffi(function(x,y) { return x+y; }): This line declares a variable named sum and assigns it a function type (int, int) => int. The => symbol represents a function type in ReScript. The implementation of the sum function is specified using the %ffi syntax, which allows embedding JavaScript code within ReScript. In this case, the JavaScript code is function(x,y) { return x+y; }, which adds the x and y parameters and returns the result.

In summary, this code defines a ReScript function sum that uses an FFI to call a JavaScript function responsible for adding two numbers.

Explain the future directive to me.

The @@future directive in ReScript is used to enable and configure the usage of experimental language features. It allows you to opt into features that are still under development or may not be fully supported or stable yet.

The @@future directive takes one or more arguments that specify the options for the enabled features. These options are comma-separated and enclosed in parentheses.

Here are a couple of options commonly used with @@future:

• uncurriedByDefault: This option specifies that uncurried functions should be used by default. Uncurried functions in ReScript are functions that take multiple arguments as a tuple, rather than currying them. Currying is the process of transforming a function that takes multiple arguments into a sequence of functions, each taking a single argument. By enabling this option, you can define functions that take multiple arguments without explicitly currying them.

• ffiArityCheck: This option enables arity checking for foreign function interface (FFI) functions. When using the %ffi syntax to embed JavaScript or other foreign code within ReScript, arity checking verifies that the number of arguments passed to the FFI function matches the expected arity. This helps catch potential errors when calling FFI functions.

It's important to note that features enabled using @@future are experimental and subject to change. They may not be fully supported or behave as expected. Therefore, it's recommended to use them with caution and be aware of the potential risks and limitations.

The @@future directive allows developers to experiment with upcoming language features and provide feedback to the ReScript development team, contributing to the evolution of the language.

[zth]

Should this be accompanied by an option in the config as well? So things can be turned on project wide.

[cristianoc]

Should this be accompanied by an option in the config as well? So things can be turned on project wide.

Yes

[ryyppy]

probably something for the upcoming rescript.json file @cometkim

[cristianoc]

probably something for the upcoming rescript.json file @cometkim

Actually we could merge the rescript.json PR pretty soon if we could gate it, no need to wait for v11. Goes both ways.

The other natural one is this #6102 as it's ready to do but we don't want to cause too many output changes for people who try out v11.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.