Core Solidity: Feedback from porting Uniswap v2

Language Design
1

I implemented the Uniswap v2 pair contract in Core Solidity . The language is farther along than I thought. Here’s some thoughts:

name: uint256, vs uint256 name in function names and storage definitions is the biggest visual difference from classic solidity. Is there a compelling reason for this? If it’s going to switch back, might be good to go ahead and do it.

Are we having function modifiers? Reentrancy protection feels a bit uglier without this.

Function visibility is coming, right? internal / external / public?

Things I needed, but assume are coming:

1. Missing globals msg.sender, block.timestamp, etc. Defined my own methods for these, but writing your own code for it is not how it should ship.
2. String support
3. Safe math must be the default
4. I shouldn't have to always type literal numbers in the code, eg uint256(0)
6. Custom Error support, rather than just returning raw custom error bytes.
7. Auto-accessors for public variables.
1 Like
2

Welcome and great to see you trying it out.

And even more so, thank you for sharing this feedback. It’s very useful. Some of your items overlap with an internal list we just discussed earlier today.
I’ve shared the post with the rest of the team.

For the general syntax, you can expect an overhaul that will make it feel more familiar to Classic Solidity. name: uint256 is what we currently prefer, since it’s how many modern languages do it. Nothing is set in stone yet, but it’s the current favorite.

Did you manage to get the Uniswap v2 contracts compiled?

3

Yes, the contracts compiled. I haven’t tested them or fuzzed them against the originals yet, but planning on doing that tomorrow.

1 Like