Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create an implicit Sway prelude #841

Closed
emilyaherbert opened this issue Feb 25, 2022 · 8 comments · Fixed by #2769
Closed

Create an implicit Sway prelude #841

emilyaherbert opened this issue Feb 25, 2022 · 8 comments · Fixed by #2769
Assignees
Labels
big this task is hard and will take a while compiler General compiler. Should eventually become more specific as the issue is triaged enhancement New feature or request team:compiler Compiler Team

Comments

@emilyaherbert
Copy link
Contributor

Per the discussion on #830, we will eventually want to have a Sway prelude akin to the Rust prelude (https://doc.rust-lang.org/std/prelude/index.html).

@emilyaherbert emilyaherbert added big this task is hard and will take a while compiler General compiler. Should eventually become more specific as the issue is triaged enhancement New feature or request forc labels Feb 25, 2022
@adlerjohn adlerjohn moved this to Todo in Fuel Network Feb 25, 2022
@adlerjohn
Copy link
Contributor

Related: #330

@mitchmindtree
Copy link
Contributor

Adding some quick thoughts on this as it was raised again recently in #2433:

The simplest approach might be to add prelude names while constructing the initial Namespace. The Namespace contains an init module that is cloned when initialising each module within a Sway project. It contains the names that should be implicitly available from every module. Perhaps we can add the prelude names to this init module upon constructing the Namespace with the condition that the std library must be a dependency.

@mohammadfawaz
Copy link
Contributor

From @SwayStar123's desription in #2433:

Heres some nominations for addition to the prelude

  • Address
  • ContractId
  • Identity
  • transfer()
  • msg_sender()
  • msg_amount()
  • msg_asset_id()
  • StorageMap
  • Vec
  • assert
  • require
  • revert

I will close #2433 in favour of this issue.

@sezna
Copy link
Contributor

sezna commented Sep 10, 2022

Hm, I think a lot of the above can remain scoped. Address, ContractId, and Identity, Vec, assert, require, and revert should probably be included. But msg_sender, transfer, msg_amount, msg_asset_id, and StorageMap can remain scoped IMO. Following Rust's prelude design, there aren't many global functions and all data structures except Vec are in std::collections

@SwayStar123
Copy link
Collaborator

Hm, I think a lot of the above can remain scoped. Address, ContractId, and Identity, Vec, assert, require, and revert should probably be included. But msg_sender, transfer, msg_amount, msg_asset_id, and StorageMap can remain scoped IMO. Following Rust's prelude design, there aren't many global functions and all data structures except Vec are in std::collections

In this regard it doesnt make sense to follow Rust, but rather Solidity's design, right?

@sezna
Copy link
Contributor

sezna commented Sep 12, 2022

That's a good question. This is really subjective. Personally, I dislike magical global functions in general, although data structures are less offensive to me. That's purely subjective though, so let's go ask in the community discord what people think.

@mohammadfawaz
Copy link
Contributor

Personally, I dislike magical global functions in general

Agree 100%. If we implement the following proposal #2463, then a lot of these functions become methods and they will be automatically available by only importing Contract (which itself might be added to the prelude already). We could even consider adding more similar types such as Block which would expose timestamp() and height() methods (instead of the free functions in https://github.com/FuelLabs/sway/blob/master/sway-lib-std/src/block.sw).

@xyx202
Copy link

xyx202 commented Sep 13, 2022

Very good

Repository owner moved this from Todo to Done in Fuel Network Sep 14, 2022
@IGI-111 IGI-111 added the team:compiler Compiler Team label Feb 10, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
big this task is hard and will take a while compiler General compiler. Should eventually become more specific as the issue is triaged enhancement New feature or request team:compiler Compiler Team
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

9 participants