User-defined value types

[chriseth]

Originally proposed by @maurelian

It should be possible to define a user-defined type that is identical to a provided value type (including operators, members, etc.), but cannot be implicitly converted to any other type, and can only be explicitly converted to and from the underlying value type.

This has the effect that arithmetic operations are impossible to perform across these types.

Example (syntax under discussion):

typedef DistanceInMeters uint;
typedef DistanceInInch uint;
typedef Price fixed128x10;

DistanceInMeters distanceToDestination;
Price buyerPrice;
Price sellerPrice;

In the above, you can do buyerPrice - sellerPrice, but you cannot do buyerPrice * distanceToDestination.

[hrkrshnn]

Currently, there is a hack to define user defined address types using empty interfaces. (Saw this in a discussion from eth security.)

interface MyAddress {}

function f(address a) returns (address) {
	MyAddress myAddress = MyAddress(a);
	return address(myAddress);
}

---

I think user defined types is a good idea. But I think the rules "cannot be implicitly converted" and "automatically derives arithmetic operations" are not consistent.

To take an example from Haskell, type is an alias and can be interchangeably used with the original type. In particular, implicit conversions and operators just work. Whereas newtype creates a new type that has stricter type requirements and can't just be converted to the underlying type. To define operations on it, one has to explicitly declare it.

Example code from Haskell's user defined types

-- Can be interchangeably used with Int
type MyInt = Int

f :: Int -> Int
f x = x + 1

-- Implicit converstion: type checks
a :: MyInt
a = 5

-- Addition and implicit conversion: type checks
b :: MyInt
b = f a

-- Creates a new type, but implicit conversions are not possible
newtype MyNewInt = MyNewInt Int

-- Implicit conversion doesn't type check
-- c :: MyNewInt
-- c = 5

c :: MyNewInt
c = MyNewInt 5

-- Doesn't type check
-- d :: Int
-- d = f c

-- Doesn't type check, since + is not defined
-- d :: MyNewInt
-- d = c + 5

newtype MyNewIntWithPlus = MyNewIntWithPlus Int

instance Num MyNewIntWithPlus where
  MyNewIntWithPlus a + MyNewIntWithPlus b = MyNewIntWithPlus (a + b)
  MyNewIntWithPlus _ * MyNewIntWithPlus _ = undefined
  signum = undefined
  abs = undefined
  fromInteger = undefined
  negate = undefined

d :: MyNewIntWithPlus
d = MyNewIntWithPlus 10

-- Now addition type checks.
e :: MyNewIntWithPlus
e = d + d

main = undefined

---

I think we should have an explicit syntax that shows that the operators are derived, and by default, none of the operators should be derived.

The syntax could look like

newtype MyInt = uint256 deriving (+, -, *, ==);
using MyInt = uint256 inheriting (+, ==);

---

As a side comment, I think the operator < for MyAddress in the first example code should be disallowed.

[maurelian]

Thanks for opening this for me @chriseth, I swear it was still on my todo list. :)

Currently, there is a hack to define user defined address types using empty interfaces. (Saw this in a discussion from eth security.)

I think I might have started that conversation. The original context at Optimism is that we would like to differentiate between addresses on L1 and L2, and prevent them from being used interchangeably.

typedef ethAddress address;
typedef ovmAddress address;

function(ovmAddress oAddr, bytes data) {
     oAddr.call(data);   // typeEror
}

I also generally like the sound of what @hrkrshnn proposes for valid operators.

[hrkrshnn]

On second thought, I'm not sure if we should allow arithmetic operators for user defined types.

The main problem is whether inbuilt safemath should apply for such types, and if yes, should unchecked blocks do wrapping arithmetic?

Perhaps the only operator that a user defined type should have is == and !=. (Even better would be making this explicit)
I would be okay with just disallowing == as well. We currently don't have == for tuples either (see #8919). Perhaps, we can think about defining operators on all such types, tuples and structs as a separate issue afterwards.

Example on how equality is handled in Haskell's newtype

newtype MyInt = MyInt Int

a :: MyInt
a = MyInt 10

a' :: MyInt
a' = MyInt 11

-- Doesn't type check, since == is not defined
-- No instance for (Eq MyInt) arising from a use of ‘==’
-- b :: Bool
-- b = a == a'

newtype MyIntWithEq = MyIntWithEq Int
                    deriving(Eq)

c :: MyIntWithEq
c = MyIntWithEq 10

c' :: MyIntWithEq
c' = MyIntWithEq 20

b :: Bool
b = c == c'

b' :: Bool
b' = c /= c'

main = undefined

---

A user can define functions to do arithmetic operations on it anyway, where the overflow behaviour is explicit.

newtype MyInt = uint256;

function add(MyInt a, MyInt b) returns (Myint c) {
   c = MyInt(uint256(a) + uint256(b));
}

function unchecked_add(MyInt a, Myint b) returns (Myint c) {
  unchecked {
    c = MyInt(uint256(a) + uint256(b));
  }
}

[chriseth]

If we want to explicitly list operators, I see this feature very much in line with the "using A for x" statement:

type NewType = uint using (+, g, f, L);

which means that for

NewType a;
NewType b;

you can do

a + b;
a.g();
a.f();
a.t(); // with t being a function of L

Alternatives for the syntax:

type NewType = uint: +, -, f;
type NewType = uint with +, -, f;
type NewType: uint using (+, -, f);
type NewType: uint (+, -, f);
type NewType(uint) using +, -, f;
type NewType is uint using +, -, f;

[chriseth]

@leonardoalt mentioned that he would like to see something like Rust's trait system in Solidity. I think we can extend the current notation to traits in the future.

[cameel]

Alternatives for the syntax:

How about reusing the syntax for libraries?

type NewType = uint;
using {+, g, f, L} for NewType;

It would also allow multiple libs to define stuff for the same type.

[frangio]

Separating the using and type declarations as in the previous comment sounds like it would allow users of a type to define more arithmetic operations for it, breaking the encapsulation benefits. I may want to define a type and disallow addition by not deriving the + operator, and I wouldn't want users to be able to add it themselves. Though I guess they'll always be able to cast back to the original type... so it's not full encapsulation, but at least the casting makes it explicit that you're breaking out of the type rules.

[hrkrshnn]

About the using syntax:

type NewType = uint;
using {+, g, f, L} for NewType;

The problem I have with this syntax is where is + coming from? We haven't defined a + with signature (NewType, NewType) -> NewType. (I'm assuming that in the above example, g and f are functions with signature (NewType, ...) -> ... and not (uint, ...) -> ...; And the binding to the latter signature should be a type error.)

The using syntax looks fine, if we want to bind a function with type (NewType, ...) -> ... to NewType and call it by NewType(value).f(...), but if we want to copy an operator from the uint to NewType, it has to be done in the definition.

---

The intuition for a syntax like

type NewType = uint deriving (==);

would be that there is a typeclass (as in Haskell) or a trait (as in rust) with the name ==. And the language already implements an instance of == on uint. When a new type is constructed, we derive the implementation of the typeclass or trait from the base type.

It's slightly weird to have typeclass / traits with the name of the operator. In haskell and rust, == would be Eq. For +, it's Additive in haskell (or part of Num, which also includes *, negate, etc.) and Add in rust.

If we want to really go in this direction, we could consider defining proper typeclasses or traits with standard names, such as Eq, Add etc. And the following syntax would actually make perfect sense:

type newType = uint deriving (Eq, Add);

The keyword derive is also present in rust, which does exactly as above. See https://doc.rust-lang.org/rust-by-example/trait/derive.html

[chriseth]

I see your point about + only being defined for uint, but I don't see why introducing a trait / typeclass would fix the issue. You would still need to have the exception that the compiler defines operators for you.

Another point about the syntax: I think we should not use = because it looks too much like a type alias. What about type newType is uint; or type newType: uint;?

[axic]

As a reference: this was discussed earlier in #1100 (and #1013, though this one shifted to non-typedef discussions).

I think one benefit now of user defined types could be that they show up as internalType in the ABI, allowing for more precise off-chain decoding/encoding/validation of calldata.

[fulldecent]

The easiest solution (i.e. let's implement this now) is to disable operators and disable anything implicit.

If you really need your custom addition function divMod(x, y) to apply to a new integer type (which is exactly just uint256 anyway) then you can rewrite the function.

Requiring explicit casting is a huge safety feature. We can all name languages that use typecasting for safety, mine is Ada.

Proposal:

type L1Address is address;
type L2Address is address;
L1Address base = L1Address(msg.sender);
base = msg.sender; // ERROR
L2Address rollup = L2Address(msg.sender);
base = rollup; // ERROR

type NFTBatchID is uint32;
NFTBatchID batchId = 16; // ERROR
batchId = NFTBatchID(16);
function getBatchFromToken(NFTBatchID batchID); // ABI is getBatchFromToken(uint32)