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

Write articles about 0.6.0 features #8057

Closed
2 of 14 tasks
chriseth opened this issue Dec 18, 2019 · 11 comments
Closed
2 of 14 tasks

Write articles about 0.6.0 features #8057

chriseth opened this issue Dec 18, 2019 · 11 comments
Assignees

Comments

@chriseth
Copy link
Contributor

chriseth commented Dec 18, 2019

  • virtual and override, public vars can override external functions, abstract contracts, no state variable shadowing
  • fallback / receive split
  • try/catch
  • array slices
  • push(element) / push() / disallow write access to .length
  • type(a**x) = type(a), payable(x) conversion for address, f.address instead of address(f)
  • global enums and structs
  • _ delimiter for hex strings
  • ABIEncdoreV2 no longer experimental, yul optimizer activated together with standard optimizer
  • new error reporter
  • disable metadata hash / switch to ipfs / swarm
  • modifier depth in source mappings
  • multiple @returns statements in natspec
  • yul / inline assembly: leave
@chriseth chriseth self-assigned this Dec 18, 2019
@chriseth
Copy link
Contributor Author

chriseth commented Jan 8, 2020

@ChrisChinchilla here is a draft for "fallback / receive split". I'll put it here until we have the new repo:

Fallback function in 0.5 and prior is used for two different purposes. One of them is safe and rather easy to understand but the second one is a low-level functionality that can easily lead to bugs if not done properly. Because of that, we split the fallback function into two different functions following thes.purposes:

First function: react when being sent ether. Can be used to reject the transfer, emit an event, forward ether (caveat) and other similar things. This is the safe part of the fallback function that is usually the only one that is needed. In 0.6.x, ure the "receive" function for that. The function is called if the contract is invok d without any data, i.e. without a function to be called. .send() and .transfer() call the receive function

Second function: implement proxy contract that forwards function calls. If a contract is invoked but no function in the contract matches the function identifier in the call data, then the fallback function is runs. This allows to implement functionalities that are split across multiple contracts or where the actual implementation of a contract is stored elsewhere.
Example: simple proxy contract

What is the danger in the way it was done in 0.x?
Problem: implement fallback function and only expect it to be called on ether transfers. It will still be run if the intended function is missing from the contract. Even worse: no error will be reported at runtime.
Example: need a good example. The problem is that if a fallback is implemented that takes ether, then it will result in some benefit to the caller. So we could have an example where a contract executes something and takes a fee in ether and you can also send it ether to do something else.

@chriseth
Copy link
Contributor Author

chriseth commented Jan 8, 2020

Oh and the example at the end should probably also contain two contracts, one that does define the function and one that does not but has a fallback function instead. Then an instance of the "wrong" contract is called from a third contract.

Also, @ChrisChinchilla , the draft is just the collection of points I want to get across, please feel free to completely rewrite it.

@GNSPS
Copy link
Contributor

GNSPS commented Jan 8, 2020

Is the article nearing completion or is help welcomed?

Diligence was thinking of writing an update to the Solidity post about 0.6.x changes. So we're happy to help on this front.

@chriseth
Copy link
Contributor Author

chriseth commented Jan 9, 2020

Created the repo to host the articles: https://github.com/ethereum/solidity-blog

@GNSPS no, it's just a draft as of now - but not sure how for @ChrisChinchilla has come until now :)

@ChrisChinchilla
Copy link
Contributor

@chriseth Sorry, was off sick the past few days, will look today.

@ChrisChinchilla
Copy link
Contributor

First draft of first post, needs example added, and then more detail based around that.

@chriseth chriseth added the L label Jan 15, 2020
@chriseth chriseth added this to the Sprint 1 milestone Jan 28, 2020
@elenadimitrova elenadimitrova removed this from the Sprint 1 milestone Jan 29, 2020
@elenadimitrova elenadimitrova removed the L label Jan 29, 2020
@chriseth
Copy link
Contributor Author

As an example, we could use an auction contract that has a bid function but no fallback function and a token sale contract that has a receive function. If we confuse the addresses after 0.6.0, we will get a revert. Pre-0.6.0 the token sale contract would only have a fallback function and thus the calling the 'bid' function would cause a token purchase.

@franzihei
Copy link
Member

To not clutter the solidity repo any further and to keep an easy overview, let's move all blog related issues to the Solidity blog repo. I will copy the list and create a new issue to keep track of everything here: ethereum/solidity-blog#39

@axic
Copy link
Member

axic commented May 6, 2020

Could also transfer this issue, @chriseth. That way the comments are kept in one place.

@franzihei
Copy link
Member

The comments are not really needed though / should have all been covered already. But go ahead if you think it's necessary @chriseth. :)

@axic
Copy link
Member

axic commented May 6, 2020

Just mentioned it as a nice feature Github provides, which could come handy in the future. I occasionally use it to move things from solc-js or to move to remix-ide.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants