Remove the module kind declaration (i.e. `script;`, `contract;`, etc) from Sway files in favour of a forc manifest field

[mitchmindtree]

Motivation

Currently, we declare a "program type" at the start of each Sway file.

This currently has a few issues:

1. All files in a project can only be library other than the project root, which can be any of the library;, script;, contract; or predicate; types. This means users are often forced to declare the library type unnecessarily, as we should be able to infer this type based on whether the file is a submodule (i.e. not the root). The compiler only needs to know the intended program type for a package as a whole (i.e. a whole tree of modules).

2. Currently forc has to parse the root src file just to check the program type (it's not safe to just grab the first line as a user might have combinations of whitespace, comments and now module-level comments preceding the declaration).

To address these concerns, we might consider moving the program type declaration field from the module level (i.e. Sway files) to the forc manifest, and treating the intended program type as an input to the compilation process.

For now, this could be an entry under the [project] table, e.g.

[project]
authors = ["name"]
entry = "main.sw"
license = "Apache-2.0"
name = "forc-pkgs"
type = "contract" # Indicates the contract program type. Could also be "script", "library" or "predicate".

Eventually we may wish to add support for individual projects to specify multiple targets, similar to how Rust allows for specifying multiple [bin] entry points for a single crate today. For now, I think a field under the [project] table would likely enable the simplest transition from the current approach.

Implementation

Steps of implementation may look something like the following:

• [ ] Add support for the project table type field to Forc.toml as above.
• [ ] Use a deprecation period to move users over to the new approach:
  • When determining the intended program type, prefer the Forc-specified field to the sway-file-specified declaration.
  • If declared in both locations but the types differ, produce a hard error.
  • Deprecate the file-specified declaration. For submodules, let the user know the declaration may be removed as the compiler can now infer it. For root modules, show the user how to declare the program type in their Forc.toml manifest.
  • Forc should produce a warning if the manifest's [project] type field is missing.
• [ ] In a following release, remove support for the in-file declarations altogether.

References

Previously mentioned:

• https://github.com/FuelLabs/sway/pull/4232/files#r1129785146
• https://github.com/FuelLabs/sway-rfcs/pull/24#discussion_r1113691196

and more places I'm sure I'm missing!

[mohammadfawaz]

Relevant: https://github.com/FuelLabs/sway/issues/2428

[nfurfaro]

Would this approach of specifying the program type in the manifest suffice to disambiguate between script and predicate types? I guess you wouldn't know from reading just the file which type you're looking at, but assuming you can still only have one of these types per forc "package", the manifest would tell you what you need to know.

It bugs me a bit that reading the src file alone would not tell me what type of program it is. I think it's worth considering the ideas of either renaming main() to script()/predicate(), or using an annotation like:

#[predicate()]
fn main() -> bool {...

[arboleya]

Maybe unrelated, but could we also have this information (program type) present on the Json ABI?

Currently, on the TS-SDK Typegen land, we ask users to specify the program type explicitly.

Ideally, this could be automatically inferred from the ABI.

cc @camsjams

[mitchmindtree]

Would this approach of specifying the program type in the manifest suffice to disambiguate between script and predicate types?

Yes

I guess you wouldn't know from reading just the file which type you're looking at, but assuming you can still only have one of these types per forc "package", the manifest would tell you what you need to know.

Yes this would be closer to Rust's approach, where you can specify both lib and one or more bin targets for a single crate. In our case rather than just lib or bin, we'd have library, script, predicate and contract. The proposal above is for just specifying a single target type under a type field, but later we could potentially enable specifying multiple targets with different entry points similar to how Rust does. There are normally ways to work around this though (e.g. split out different packages for different targets) so I don't think the multi-target approach should be a big priority.

It bugs me a bit that reading the src file alone would not tell me what type of program it is.

It's worth keeping in mind that today, we have the opposite problem, i.e. you can't know what the type of a package is just by reading it's manifest. It's arguably more important at the manifest level, as there are all sorts of places where forc can use that information before parsing begins (e.g. for forc deploy or forc run, validating contract dependency declarations, etc).

[nfurfaro]

It's arguably more important at the manifest level, as there are all sorts of places where forc can use that information before parsing begins

Yeah, makes sense.