User defined value types #11806

hrkrshnn · 2021-08-16T12:32:30Z

Closes #11531

TODO

libsolidity/analysis/DeclarationContainer.cpp

libsolidity/analysis/DeclarationTypeChecker.cpp

libsolidity/analysis/TypeChecker.cpp

libsolidity/parsing/Parser.h

libsolidity/parsing/Parser.cpp

libsolidity/ast/Types.h

docs/types/value-types.rst

chriseth · 2021-08-17T18:20:02Z

docs/types/value-types.rst

+  ``==`` is disallowed. One can use operators or bound member functions by explicitly converting it
+  to the underlying type.
+
+The following example demonstrates a custom type ``MyAddress`` which is an abstraction over the


Shouldn't we use an example that also shows the usefulness of this concept?

libsolidity/ast/AST.h

libsolidity/ast/Types.cpp

test/libsolidity/syntaxTests/userDefinedValueType/all_value_types.sol

hrkrshnn · 2021-08-18T11:02:16Z

test/libsolidity/syntaxTests/userDefinedValueType/explicit_conversions.sol

+type MyAddress is address;
+
+function f() pure {
+    // TODO Should we allow explicit conversions from literals?


I think yes. This is similar to how newtype semantics work in haskell and rust (?)

I'm not too sure about it - wouldn't it create ambiguities? We have to at least check that implicit conversion from the literal to the underlying type is possible.

libsolidity/ast/Types.h

chriseth · 2021-08-18T13:47:35Z

libsolidity/ast/Types.h

+	}
+	bool nameable() const override { return m_underlyingType.nameable(); }
+
+	std::string toString(bool _short) const override { return "UserDefinedValueType(" + m_underlyingType.toString(_short) + ")"; }


Shouldn't this also include the name of the type? (as we do for struct)

chriseth · 2021-09-08T10:34:16Z

libsolidity/ast/Types.cpp

 	}
+	else if (m_actualType->category() == Category::UserDefinedValueType)
+	{
+		auto& userDefined = dynamic_cast<UserDefinedValueType const&>(*m_actualType);


Suggested change

auto& userDefined = dynamic_cast<UserDefinedValueType const&>(*m_actualType);

auto const& userDefined = dynamic_cast<UserDefinedValueType const&>(*m_actualType);

But the const here is redundant, isn't it?

It is, but may be nice to mention it - we usually do.

chriseth · 2021-09-08T10:37:33Z

libsolidity/codegen/ExpressionCompiler.cpp

+			if (kind == FunctionType::Kind::Wrap)
+				solAssert(argumentType->isImplicitlyConvertibleTo(userDefinedType->underlyingType()), "");
+
+			acceptAndConvert(*arguments[0], *function.parameterTypes()[0], true);


Do we really need to do cleanup?

Can you assert that the implicit conversion is possible, please?

I've removed the cleanup and added one more assert.

chriseth · 2021-09-08T10:39:50Z

libsolidity/codegen/ExpressionCompiler.cpp

+			Type const* argumentType = arguments.at(0)->annotation().type;
+			solAssert(argumentType, "");
+			FunctionType::Kind kind = functionType->kind();
+			auto userDefinedType = kind == FunctionType::Kind::Wrap ?


Wouldn't it be easier and less confusing to retrieve this from _functionCall.expression? Maybe not.

On that note test cases for stuff like (MyType).wrap and the like would be good.

chriseth · 2021-09-08T17:19:15Z

docs/abi-spec.rst

 +-------------------------------+-----------------------------------------------------------------------------+
 |:ref:`enum<enums>`             |``uint8``                                                                    |
 +-------------------------------+-----------------------------------------------------------------------------+
+|:ref:`user defined value types |exactly as its underlying value type                                         |


Sorry, the "exactly" was not meant literally. The text above table says "on the right column the ABI types that represent them", so it should be enough to say "its underlying value type" or "the underlying value type".

chriseth · 2021-09-08T17:21:38Z

libsolidity/analysis/TypeChecker.cpp

+		case FunctionType::Kind::Wrap:
+		case FunctionType::Kind::Unwrap:
+		{
+			typeCheckFunctionGeneralChecks(_functionCall, functionType);


libsolidity/codegen/ExpressionCompiler.cpp

libsolidity/codegen/ir/IRGeneratorForStatements.cpp

chriseth · 2021-09-08T17:28:06Z

libsolidity/codegen/ir/IRGeneratorForStatements.cpp

+		else
+			solAssert(type(*arguments.at(0)).category() == Type::Category::UserDefinedValueType, "");
+
+		define(_functionCall, *arguments.at(0));


This actually skips one conversion - but would be fine for me, since the conversion is a no-op (and I hope it stays like that).

Also added a test.

ekpyron · 2021-09-09T09:28:16Z

libsolidity/ast/AST.h

+ * User defined value types, i.e., custom types, for example, `type MyInt is int`. Allows creating a
+ * zero cost abstraction over value type with stricter type requirements.
+ */
+class UserDefinedValueTypeDefinition: public Declaration


I still think this is a really bad name for the node :-D - but well.

ekpyron · 2021-09-09T09:29:40Z

test/libsolidity/syntaxTests/userDefinedValueType/in_parenthesis.sol

+    (MyInt).wrap;
+    (MyInt).wrap(5);
+    (MyInt).unwrap;
+    (MyInt).unwrap(MyInt.wrap(5));


Syntactically this is really not interesting - this should be a semantics test!

I can move this.

Did it here: #11914

fulldecent

The fixed math library claims the division function is to the "nearest integer" but actually it rounds down.

hrkrshnn · 2021-09-09T12:56:12Z

@fulldecent Thanks for noticing. Will update the comment.

fulldecent · 2021-09-09T17:54:20Z

Thank you! Looks good now

hrkrshnn changed the title ~~User defined types~~ User defined value types Aug 16, 2021