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

Assembly libraries #13472

Closed
k06a opened this issue Sep 1, 2022 · 6 comments
Closed

Assembly libraries #13472

k06a opened this issue Sep 1, 2022 · 6 comments
Labels
language design :rage4: Any changes to the language, e.g. new features

Comments

@k06a
Copy link

k06a commented Sep 1, 2022

Abstract

We have assembly/yul functions but can't reuse them among assembly blocks. Let's have assembly libraries!

Motivation

Would allow us to reuse assembly code

Specification

Let's have it like this:

assembly library AsmERC20 {
    function approve(token, to, amount) {
        // ...
    }
    function transfer(token, to, amount) {
        // ...
    }
}

and use it like this:

assembly {
    AsmERC20.transfer(token, to, amount);
}
// ...
assembly {
    AsmERC20.approve(token, to, amount);
}

Backwards Compatibility

Not required

@ekpyron ekpyron moved this to Triage in Solidity Focus Board Sep 2, 2022
@ekpyron ekpyron moved this from Triage to Design/Decide in Solidity Focus Board Sep 2, 2022
@ekpyron
Copy link
Member

ekpyron commented Sep 2, 2022

Do you agree that this is a duplicate of #9282?
The idea there was to allow file level inline assembly blocks that would allow to define reusable functions. Being able to namespace those would of course be nice - but that could be done via the import mechanism, resp. is part of the more general issue of allowing inner-file-namespacing.

So given that I think there's no need for assembly libraries as special construct and file-level assembly blocks are the simpler and more consistent option for this.

I'll go ahead and close this as duplicate and maybe re-triage #9282 - but if you disagree, feel free to reopen!

@ekpyron ekpyron closed this as completed Sep 2, 2022
Repository owner moved this from Design/Decide to Done in Solidity Focus Board Sep 2, 2022
@k06a
Copy link
Author

k06a commented Sep 2, 2022

@ekpyron any idea when we could have any of these?

@cameel
Copy link
Member

cameel commented Sep 5, 2022

As @ekpyron said, we're going to retriage #9282, which will involve figuring out where it fits in our short- and long-term roadmap. So no decision yet but the way I see it personally: there are enough important features in the short-term that we won't get to it very soon but it's also important enough to be considered a core feature and be somewhere on the roadmap.

Unless... @chriseth did you consider #9282 to be a part of #13319? :)

@cameel cameel added the language design :rage4: Any changes to the language, e.g. new features label Sep 5, 2022
@k06a
Copy link
Author

k06a commented Sep 5, 2022

@cameel @ekpyron I am not sure having global assembly block is same good as having assembly library. Assembly library could allow to have only assembly functions declarations. Please consider this idea.

@ekpyron
Copy link
Member

ekpyron commented Sep 5, 2022

A global assembly block would also only allow function declarations in it (I don't see what anything but function definitions in them would mean) - and those would be globally available.
So the only actual difference I see is that an assembly library would implicitly introduce a namespace for them. That's of course nice, but part of the larger issue of namespacing globally-scoped items in general. This can right now be achieved using the import mechanism, but we may also provide a file-local mechanism in the future.

Given that - what remaining advantage would assembly libraries have concretely?

@ekpyron
Copy link
Member

ekpyron commented Sep 5, 2022

I.e. from what I understand the plan to have global assembly blocks is exactly your suggestion of assembly libraries minus namespaces - and the issue of namespaces is best solved uniformly together with namespacing free functions, etc., isn't it?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
language design :rage4: Any changes to the language, e.g. new features
Projects
Archived in project
Development

No branches or pull requests

3 participants